Extensión del framework OWLAPI para la administración y razonamiento sobre grandes ontologı́as Manuel E. Puebla-Martı́nez1 , José M. Perea-Ortega2 , and Alfredo Simón-Cuevas3 1 Universidad de las Ciencias Informáticas, La Habana, Cuba mpuebla@uci.cu 2 Universidad de Extremadura, Badajoz, España jmperea@unex.es 3 Universidad Tecnológica de La Habana “José Antonio Echeverrı́a”, Cujae La Habana, Cuba asimon@ceis.cujae.edu.cu Abstract. Nowadays, managing and reasoning on large ontologies is considered a resource-intensive task, mainly due to the complexity of the reasoning algorithms involved. In addition, most of the existing tools to manage large ontologies require high-performance computers, which could make some users hard to find a feasible solution. This paper presents an approach to manage and reason on OWL2 large ontologies by using the OWLAPI framework. The main novelty focuses on the development of a software solution that allows managing large ontologies, together with the development of specific search procedures in OWLAPI that would require the use of reasoners in the case of this type of ontologies. The proposed approach was tested by generating a spatial ontology on the region of Marianao (Cuba) and launching several queries on it. The results show the great performance of the approach developed. Keywords: Large Ontologies, Knowledge Representation, Reasoning on Large ontologies, OWLAPI, OWL2 Resumen. En la actualidad, la administración y el razonamiento en ontologı́as grandes se considera una tarea de uso intensivo de recur- sos, principalmente debido a la complejidad de los algoritmos de ra- zonamiento involucrados. Además de este problema, la mayorı́a de las herramientas existentes para administrar grandes ontologı́as requieren computadoras de alto rendimiento, lo que podrı́a hacer que para algunos usuarios fuese difı́cil encontrar una solución viable. En esta investigación se presenta un enfoque para gestionar y razonar sobre ontologı́as grandes utilizando el framework OWLAPI. La principal novedad se centra en el desarrollo de una solución de software que permite administrar ontologı́as grandes, unido al desarrollo de procedimientos de búsqueda especı́ficos en OWLAPI que necesitarı́an el uso de razonadores para el caso de on- tologı́as con caracterı́sticas similares a las descritas en este trabajo. El enfoque propuesto fue probado generando una ontologı́a espacial en la 125 región de Marianao (Cuba) y lanzando varias consultas al respecto. Los resultados muestran el rendimiento del enfoque desarrollado. Palabras claves: Ontologı́as grandes, Representación del conocimiento, Razonando sobre ontologı́as grandes, OWLAPI, OWL2 1. Introducción El uso de ontologı́as es cada vez más requerido por aquellos sistemas de información que necesitan procesar la semántica asociada al contenido, como por ejemplo los sistemas de Recuperación de Información Geográfica (GIR, si- glas en inglés). En este ámbito, las ontologı́as resultan muy útiles para describir la semántica y relacionar los datos espaciales, generar nuevo conocimiento es- pacial y mejorar la toma de decisiones en este dominio. Sin embargo, el uso efectivo de las ontologı́as no solo requiere su codificación en un lenguaje formal, sino también requiere de un soporte adecuado de herramientas para su admin- istración, que posibiliten el razonamiento automático o la inferencia a partir del conocimiento que representan. La presente investigación se desarrolla en el marco de un proyecto que tiene por objetivo el desarrollo de un GIR sopor- tado en el uso de una ontologı́a geográfica. La ontologı́a se genera de forma semiautomática usando un método que aprovecha la diversidad de fuentes de información y ofrece la posibilidad de obtener una ontologı́a que conceptualiza cualquier lugar geográfico. En este contexto, fue utilizado dicho método para obtener una ontologı́a geográfica de uno de los municipios de La Habana (Cuba), especı́ficamente Mar- ianao, la cual contenı́a más de cuatro mil individuos, 76 millones de propiedades de objetos, y más de 100 mil propiedades de datos; resultando ser una ontologı́a grande. Si se construyese la ontologı́a de toda Cuba o del Continente Americano, los valores antes señalados crecerı́an de manera exponencial pudiendo llegar a alcanzar los 30 GB de memoria o más. Esto condujo a plantearse el siguiente problema: ¿cómo administrar y razonar sobre ontologı́as con tales dimensiones? La mayor parte de los editores de ontologı́as hacen un uso intensivo de la memo- ria principal y no son particularmente adecuados para el razonamiento sobre ontologı́as con millones de instancias, como las que a menudo son necesarias para las aplicaciones que requieren representar y describir semánticamente datos espaciales del mundo real. La integración de las Bases de Datos (DB, siglas en inglés) parece ser la solución, ya que estas aprovechan las ontologı́as para in- crementar su semántica, mientras que las ontologı́as se benefician de las DB para estructurar y almacenar grandes cantidades de instancias. Como resultado, muchas áreas de investigación están surgiendo y los trabajos resultantes de esta complementariedad son enormes [12]. OWLAPI (Ontology Web Language API, en inglés), es el framework utilizado para administrar la ontologı́a a ser utilizada por el sistema GIR que se desar- rolla. A favor de OWLAPI se dirá que es el framework utilizado por el editor 126 de ontologı́as más utilizado actualmente: Protégé 1 . Sin embargo, este framework no soporta ontologı́as como las que se generan en esta investigación, al menos con un hardware estándar, pues el mismo carga la información del fichero OWL en memoria RAM. Algo similar sucede con los razonadores que trabajan con memoria interna: Pellet, FaCT++, HermiT, TrOWL, RACER, entre otros. Es- tos, además de cargar la ontologı́a, necesitan generar nuevo conocimiento, lo cual implica la ejecución de complejos algoritmos que deben verificar una gran var- iedad de restricciones debido al alto grado de expresividad del lenguaje OWL2. El editor de ontologı́as más popular, Protégé, tampoco es capaz de cargar una ontologı́a con las caracterı́sticas descritas en este artı́culo, utilizando el frame- work OWLAPI para administrar la ontologı́a. Todos ellos generan el conocido error “Out of Memory” cuando se intenta cargar una ontologı́a grande. En este trabajo se presenta una extensión al framework OWLAPI para ad- ministrar y razonar sobre grandes ontologı́as, basada en los principios de un sis- tema OBDB (Ontology Based Data Base, en inglés). De este modo, una ontologı́a se considera grande cuando su ABOX supere o iguale los valores obtenidos y ya descritos en la ontologı́a generada de forma automática para este trabajo. El ABOX se considera uno de los tres componentes en los que se divide con- ceptualmente una ontologı́a, y contiene afirmaciones de rol entre individuos de la ontologı́a (por ejemplo, hasChild (John, Mary)) y afirmaciones de pertenencia (por ejemplo, (John:Man)). La solución presentada se apoya en el framework OWLAPI y permite administrar y satisfacer las necesidades de razonamiento del futuro sistema GIR a desarrollar. Por otro lado, el futuro sistema GIR a desarrollar necesitará trabajar con el lenguaje ontológico OWL2, y no con RDF, OWL, OWL2-QL o OWL2-RL; los cuales son lenguajes menos expresivos y utilizados en las herramientas encon- tradas en el análisis del estado del arte. 2. Trabajo relacionado OWLAPI es una API de alto nivel para trabajar con ontologı́as OWL2, por lo que está estrechamente alineada con la especificación estructural OWL2. Soporta el análisis gramatical y la traducción en las sintaxis definidas en la especificación W3C (sintaxis funcional, RDF/XML, OWL/XML y la sintaxis de Manchester OWL); manipulación de estructuras ontológicas; y el uso de motores de razonamiento. La implementación de referencia de la OWLAPI, escrita en Java, incluye validadores para los distintos perfiles OWL 2 QL, OWL2 EL y OWL2 RL. El OWLAPI tiene un uso extendido en una variedad de herramientas y aplicaciones [9]. La mayor limitante de OWLAPI está en la necesidad de cargar el fichero OWL en memoria RAM, la cual es muy limitada si comparamos los valores medios actuales con el tamaño de las ontologı́as grandes. Los sistemas DBBO (DataBase Based on Ontologies, en inglés), también conocidos como OBDA (Ontology-Based Data Access, en inglés), se han con- vertido en un popular paradigma para acceder a una o varias fuentes de datos 1 http://protege.stanford.edu 127 mediante el uso de ontologı́as. Estos sistemas aprovechan las ontologı́as para in- crementar su capacidad de administrar información semántica. En los sistemas DBBO, los usuarios acceden a los datos a través de una capa conceptual (ab- stracción de los aspectos especı́ficos relacionados con las fuentes de datos), que proporciona un cómodo vocabulario de consulta. La capa conceptual es repre- sentada generalmente mediante una ontologı́a en RDF u OWL, y se conecta a las bases de datos relacionales subyacentes utilizando asignaciones R2RML. Cuando se realiza una consulta SPARQL sobre la ontologı́a, el sistema DBBO explora las asignaciones representadas para recuperar elementos de las fuentes de datos y construir las respuestas [4]. Los sistemas DBBO no permiten hacer cambios en la DB a través de la ontologı́a, debido a que en los casos generales donde hay asignaciones complejas arbitrarias entre la ontologı́a y la DB, este problema no admite una solución general y constituye un problema de investi- gación abierto hoy dı́a. Esto es conocido en bases de datos como el “view update problem” [7]. La razón es que, en general, debido a las asignaciones, no hay una manera única para propagar una actualización especı́fica del nivel de la ontologı́a a la base de datos subyacente. Otra limitación de los sistemas DBBO es que no están diseñados para soportar ontologı́as arbitrarias en OWL2, debido a que su función principal es acceder a grandes DB a través de una ontologı́a, por lo que en general se usan lenguajes menos expresivos como es el caso de OWL2-QL. Al- gunos ejemplos de sistemas DBBO son Ontop2 , Optique [3], GraphDB3 , RDFox4 y OntoDB [5]. Por otra parte, en los últimos años han surgido los sistemas OBDB (Ontol- ogy Based DataBase, en inglés), un modelo que permite almacenar y consultar ontologı́as con una gran cantidad de instancias. Los sistemas OBDB también aprovechan los beneficios de las funcionalidades ofertadas por los Sistemas de Administración de Bases de Datos Relacionales (RDBMs, siglas en inglés), como son: rendimiento en las consultas, almacenamiento eficiente de los datos, admin- istración de transacciones, entre otras. Ejemplos de estos sistemas son: Sesame Database Manager 5 , DLDB-OWL [13], OWLIM [11], InstanceStore [10], Min- erva [17], DBOWL [15], OntoMinD [1], OwlOntDB [6] y FGOLD [2]. En [17] se reporta una comparación entre Minerva y Sesame Database Man- ager, DLDB-OWL, OWLIM e InstanceStore, concluyéndose como ventajas del primero: 1) Soporta ontologı́as en OWL-DL con una inferencia completa sobre el TBOX, pero para ontologı́as en OWL-Lite con un máximo de tripletas RDF de 2.200.000. 2) El proceso de razonamiento y evaluación que se lleva a cabo como parte de las consultas se realizan en memoria externa, materializando to- dos los resultados de inferencia en la DB, lo que la hace una herramienta más adecuada para manejar grades ontologı́as. 3) La alta escalabilidad y optimización de consultas, tanto para Minerva como para DLDB-OWL. Sin embargo, Min- 2 http://ontop.inf.unibz.it 3 http://ontotext.com/products/graphdb 4 http://www.cs.ox.ac.uk/isg/tools/RDFox 5 http://www.sesamedatabase.com 128 erva no soporta OWL2, lo cual limita su nivel de expresividad. Tampoco soporta expresiones de clases en las consultas de usuarios. Por otro lado, OntoMinD comparte con Minerva la segunda ventaja enun- ciada en el párrafo anterior, pero no deja claro si soporta OWL2. DBOWL es un razonador escalable, que soporta razonamiento completo OWL-DL para on- tologı́as con ABOX bien grandes (billones de instancias). Sin embargo, a pesar de que está licenciado con licencia GNU-GPL según el sitio oficial de la univer- sidad de Manchester, no se ha encontrado la manera de descargarlo y utilizarlo de manera local. Los autores solo brindan la posibilidad de utilizarlo a través de servicios web. OwlOntDB provee una completa cobertura de razonamiento sobre ontologı́as en OWL2-RL, no ası́ sobre ontologı́as en OWL2, diferenciándose del resto de las herramientas analizadas. Sin embargo, no se ha logrado localizar la herramienta para evaluar su utilización. En [14] se considera la ontologı́a SUMO (Suggested Upper Merged Ontology, en inglés) como una ontologı́a grande, sin embargo la misma solo ocupa 36 MB en memoria. En [16] se propone el ra- zonador Chainsaw para grandes ontologı́as, sin embargo, los propios autores reconocen que dicho razonador no es capaz de razonar sobre ontologı́as con las caracterı́sticas mencionadas en este trabajo, debido a que no está preparado para dividir grandes ontologı́as sin ser cargadas previamente en memoria interna. En [8] se evalúan los sistemas Sesame Database Manager y DLDB-OWL con la uti- lización de “Large OWL DataSets”. Los conjuntos de datos pequeños son de 15 ficheros OWL y un total de 8 MB, y los grandes conjuntos de datos poseen 999 y 583 MB. En [10] se propone cierto grado de escalabilidad con más de 100.000 individuos, especificando que el resto de las aplicaciones existentes fallan con esa cantidad. Solo el caso de DBOWL (billones de individuos) parece ser comparable con las ontologı́as abordadas en este trabajo en cuanto a cantidad de individuos, no ası́ en cuanto a tamaño del fichero OWL, pues en la evaluación de DBOWL realizada en [15] solo utilizan ontologı́as de 100 y 200 MB. Después de analizar las propuestas de otros autores, se concluye que las grandes ontologı́as de la mayorı́a de las investigaciones actuales no son com- parables en cuanto a su dimensión con las ontologı́as que se presentan en este trabajo, las cuales superan en tamaño a las encontradas en el estado del arte. En el análisis del estado del arte sobre los sistemas DBBO se identificaron dos limitaciones fundamentales: 1) La imposibilidad de hacer cambios en las DB a través de la ontologı́a generada (sólo se permite consultar la DB a través de la ontologı́a). 2) No están diseñados para soportar ontologı́as arbitrarias en OWL2. Esta última limitación también es identificada en los sistemas OBDB, unido a la imposibilidad de trabajar con el concepto de ontologı́a grande dado en esta investigación. La solución propuesta en este artı́culo resuelve las limitaciones identificadas, aunque en cuanto a las potencialidades de razonamiento, solo satisface las condi- ciones de diseño y necesidades del futuro sistema GIR. Satisfacer todas las posi- bilidades de razonamiento sobre una ontologı́a OWL2 con las caracterı́sticas descritas, es un trabajo mucho más extenso y profundo, aunque viable en una futura investigación y parcialmente abordado en la solución OwlOntDB [6]. 129 Fig. 1: Asignación de responsabilidades entre el framework OWLAPI y la Base de Datos 3. Solución propuesta 3.1. Administración de la ontologı́a Para lograr que el framework OWLAPI soportara la administración de grandes ontologı́as fue necesario extraer algunos datos del fichero OWL y almacenarlo en una DB. En la solución propuesta se decidió extraer del fichero OWL gestionado por OWLAPI, algunos datos pertenecientes al ABOX y mantener ı́ntegramente el TBOX de la ontologı́a, de forma similar a los sistemas OBDB analizados. Esto se hizo con el objetivo de poder utilizar los razonadores en memoria interna en algunas tareas especı́ficas y ası́ mantener la capacidad de razonamiento sobre la ontologı́a. Los razonadores existentes están diseñados para realizar procesos de inferencia solo sobre lo incluido en el fichero OWL de la ontologı́a, fundamen- talmente sobre el TBOX. Los datos del ABOX almacenados en la DB fueron las relaciones de objeto expresadas entre pares de individuos (Object Property Assertion Axioms) y la asignación de valores a las propiedades de datos (Data Property Assertion Axioms). La Figura 1 ilustra de forma gráfica la asignación de responsabilidades entre el framework OWLAPI y la DB, en el momento de gestionar los componentes de la ontologı́a. Al menos para la ontologı́a geográfica generada en este trabajo, esa modifi- cación fue suficiente para lograr que el framework OWLAPI y el editor Protégé cargaran la información restante en el fichero OWL. Sin embargo, ninguno de los razonadores de memoria interna antes mencionados fue capaz de razonar so- bre la ontologı́a restante en el fichero OWL, al menos con el hardware utilizado en esta investigación, debido a que los individuos continúan siendo almacena- dos en el fichero OWL gestionado por OWLAPI. Debido a la simplicidad de la información a almacenar en memoria externa, inicialmente se utilizó como medio de almacenamiento en memoria externa los ficheros. El fichero donde se almacenaron las relaciones de objeto expresadas entre pares de individuos y la asignación de valores a las propiedades de datos obtuvo un tamaño de 10 GB. Al hacer varias pruebas, los autores notaron que el tiempo de acceso a la infor- mación era demasiado elevado y la frecuencia con la que se debı́a acceder a los 130 Fig. 2: Modelo fı́sico de la DB utilizada mismos también. Por tal motivo, se decidió utilizar una DB, cuyo modelo fı́sico se ilustra en la Figura 2. La solución desarrollada consta de los mecanismos nece- sarios para que las instancias de propiedades puedan ser integradas nuevamente en su forma tradicional en el fichero OWL, siempre y cuando la memoria interna del hardware soporte el crecimiento de la ontologı́a. 3.2. Razonando sobre grandes ontologı́as desde OWLAPI Una vez cargada la ontologı́a grande en el framework OWLAPI era necesario hacer algunas operaciones sobre ella que exigı́an el uso de los razonadores, lo cual continuaba siendo una limitación a pesar de las modificaciones realizadas. En este sentido, se implementaron las operaciones necesarias sin el uso de un razonador y solo apoyándose en los recursos brindados por OWLAPI. Las operaciones de inferencia desarrolladas fueron: 1. Buscar las subclases directas e indirectas de una clase. 2. Identificar los individuos directos e indirectos de una clase, teniendo en con- sideración la equivalencia entre clases y entre individuos. 3. Identificar las clases topes, es decir, las clases que no son subclases de ninguna clase. 4. Identificar todas las clases equivalentes a una clase, considerando que la relación de equivalencia es transitiva. 5. Identificar el conjunto de superclases de una clase. 6. Obtener el conjunto de individuos que están relacionados con otro a través de una propiedad de objeto, teniendo en consideración las caracterı́sticas de la propiedad de objeto expresada en OWL: simetrı́a, funcional, transitividad, inversa, equivalencia. 7. Obtener el conjunto de literales asociados a una propiedad de datos para un individuo en particular. El Algoritmo 1 muestra el pseudocódigo implementado para obtener la op- eración de inferencia número uno, formado por dos métodos pertenecientes a la clase Ontology construida para encapsular el framework OWLAPI. Algoritmo 1: Algoritmo de la operación de inferencia 1 Entrada : La c l a s e a l a c u a l s e l e b u s c a r á n l a s s u b c l a s e s ( o w l C l a s s ) y l a c o n d i c i ó n p a r a s a b e r s i l a s s u b c l a s e s a b u s c a r s e r á n d i r e c t a s o 131 indirectas ( direct ). S a l i d a : Un c o n j u n t o con l a s s u b c l a s e s d e l p a r á m e t r o o w l C l a s s . Metodo1 : Set G e t S u b c l a s s N o t R e a s o n e r ( OWLClass o w l C l a s s , b o o l e a n d i r e c t ) Inicio 1 ) C r e a r un c o n j u n t o v a cı́ o de o b j e t o s c l a s e s ( o w l C l a s s e s ) 2 ) I n v o c a r y r e t o r n a r e l r e s u l t a d o d e l método G e t S u b c l a s s N o t R e a s o n e r que e s t á s o b r e c a r g a d o , con l o s p a r á m e t r o s o w l C l a s s , o w l C l a s s e s y d i r e c t Fin Metodo2 ( s o b r e c a r g a a l Método 1 ) : G e t S u b c l a s s N o t R e a s o n e r ( OWLClass OwlClass , Set l i s t R e s u l t , boolean d i r e c t ) Inicio i f ( OwlClass != n u l l ) { − Guardar en l i s t t o d o s t o d o s l o s axiomas de t i p o s u b c l a s s p a r a l a s u p e r c l a s e OwlClass . − Para cada o b j e t o p r e s e n t e en l i s t h a c e r : A ñadir a l i s t R e s u l t l a s u b c l a s e d i r e c t a que e s t á en cada axioma almacenado en l i s t . } i f ( ! d i r e c t ){ // e s d e c i r , s i p i d e n l a s s u b c l a s e s i n d i r e c t a s Para cada s u b c l a s e d i r e c t a de OwlClass h a c e r : − I n v o c a r r e c u r s i v a m e n t e a l método GetSubclassNotReasoner ( l a subclase , l i s t R e s u l t , d i r e c t ) } Retornar l i s t R e s u l t Fin 4. Resultados A través de la solución expuesta se logró administrar una ontologı́a geográfica que conceptualiza los lugares geográficos del municipio Marianao, cuya com- posición y caracterı́sticas se muestran en la Tabla 1. El fichero OWL (sin las relaciones de objeto expresadas entre pares de individuos) se ha dejado disponible para la comunidad cientı́fica6 . Clases 722 Clases equivalentes 12 Relaciones taxonómicas o subclases 954 Individuos 4.665 Relaciones de objeto entre pares de individuos 76.398.888 Propiedades de datos con valor en individuos 102.755 Pares de individuos similares 13.321 Anotaciones 728 Tamaño en memoria externa 15.310 KB (sin aserciones de propiedades) Table 1: Caracterización de la ontologı́a geográfica del municipio Marianao 6 http://sinai.ujaen.es/wp-content/uploads/2017/12/ OntoMarianao-OWLfile-2MB.rar 132 En la Tabla 2 se muestran los resultados de las funcionalidades de inferencia desarrolladas sobre el framework OWLAPI para la ontologı́a de Marianao. En dicha tabla, la columna Tipo hace referencia al número de operación de razon- amiento o inferencia mostrada en la Sección 3.2. Id Consulta Información recuperada Tipo Subclases 1) aerodrome 2) aiport directas e Q1 indirectas En la ontologı́a la clase aiport es subclase 1 de la clase directa de aerodrome y esta a su vez subclase aeroway directa de aeroway 1) OSM-24047147-26-08 2) OSM-252369011- Hangar 3) OSM-252369012-Hangar 4) OSM- 259849768-Aerodromo-Ciudad-Libertad 5) Geo-8554333-Ciudad-Libertad-Airport 6) DB- Instancias osm new aeroways-2 7) DB-osm new aeroways-3 directas e Además de lo expuesto en Q1, hay que con- Q2 indirectas 2y4 de la clase siderar que la clase aeroway es equivalente a aeroway osm new aeroways. Los 4 primeros resultados son instancias directas de aeroway. El quinto es instancia directa de airport, y las dos últimas, instancias directas de osm new aeroways Clases Topes Q3 en la on- 1) SpatialObject 3 tologı́a Calles que 1) Avenida 51 2) 130 3) 116 4) 128 5) 120 6) 118 ... cruzan la Q4 localidad de Se obtuvieron 36 resultados (se muestran 6 6 Los Pocitos ejemplos) Objetos es- 1) Arroyo Bañabuey 2) Policlı́nico Docente 27 de paciales en noviembre 3) Plaza de Marianao 4) Los-Pocitos Q5 6 Los Pocitos 5) Plaza-de-Marianao ... Superclases 1) boundary 2) GeonameConcept 3) SpatialObject de Admin- istrative- La clase AdministrativeBoundary es sub- Q6 5 Boundary clase de boundary y de GeonameConcept, las cuales a su vez son subclases de SpatialObject Table 2: Operaciones realizadas sobre la ontologı́a geográfica generada 133 Todos los experimentos expuestos en este trabajo fueron realizados sobre un hardware con un CPU Mobile DualCore Intel Core i5-2430M, 2800 MHz (28 x 100) y 4 GB de memoria RAM. 5. Conclusiones En este trabajo se presenta una extensión del framework OWLAPI que per- mite la administración y el razonamiento sobre grandes ontologı́as. Las pruebas realizadas demuestran la viabilidad de la solución para satisfacer las necesidades de información de un futuro sistema de Recuperación de Información Geográfica. El resultado obtenido en este trabajo puede ser utilizado en cualquier ámbito donde se necesite administrar y razonar sobre ontologı́as con las caracterı́sticas descritas. Como trabajo futuro, se podrı́a aumentar el número de funcionali- dades implementadas sin la necesidad de un razonador, ası́ como trasladar los individuos de la ontologı́a hacia la DB. Agradecimientos Los autores desean agradecer, de manera especial, los criterios y recomen- daciones aportadas por el profesor Dr. C. Ignazio Palmisano, de la Universidad de Manchester, el cual sugirió la realización de este artı́culo a través de uno de sus comentarios. Igualmente, al profesor Dr. C. Diego Calvanese, de la Facultad de Ciencias de la Computación de la Universidad de Bozen-Bolzano, por sus intercambios relacionados con la herramienta Ontop y los sistemas DBBO. Este trabajo también ha sido parcialmente financiado por el Ministerio de Economı́a y Competitividad del Gobierno de España, proyecto REDES (TIN2015- 65136-C2-1-R). References 1. Al-Jadir, L., Parent, C., Spaccapietra, S.: Reasoning with large ontologies stored in relational databases: The OntoMinD approach. Data Knowl. Eng. 69(11), 1158– 1180 (2010) 2. Bakhtouchi, A.: FGOLD: A Flexible and Graphical Ontology-based Database Ready for Use. International Journal on Human Machine Interaction 2(2), 32–49 (2015) 3. Calvanese, D., Giese, M., Haase, P., Horrocks, I., Hubauer, T., Ioannidis, Y., Jiménez-Ruiz, E., Kharlamov, E., Kllapi, H., Klüwer, J., Koubarakis, M., Lam- parter, S., Möller, R., Neuenstadt, C., Nordtveit, T., Özcep, O., Rodrı́guez Muro, M., Roshchin, M., Ruzzi, M., Savo, F., Schmidt, M., Soylu, A., Waaler, A., Zheleznyakov, D.: Optique: OBDA Solution for Big Data. In: Poster track of the Extended Semantic Web Conference (2013) 4. Calvanese, D., Cogrel, B., Komla-Ebri, S., Kontchakov, R., Lanti, D., Rezk, M., Rodriguez-Muro, M., Xiao, G.: Ontop: Answering SPARQL queries over relational databases. Semantic Web 8(3), 471–487 (2017) 134 5. Dehainsala, H., Pierra, G., Bellatreche, L.: Ontodb: An ontology-based database for data intensive applications. In: Ramamohanarao, K., Krishna, P.R., Mohania, M.K., Nantajeewarawat, E. (eds.) DASFAA. Lecture Notes in Computer Science, vol. 4443, pp. 497–508. Springer (2007) 6. Faruqui, R.U., MacCaull, W.: OwlOntDB: A Scalable Reasoning System for OWL 2 RL Ontologies with Large ABoxes. In: Weber, J., Perseil, I. (eds.) FHIES. Lecture Notes in Computer Science, vol. 7789, pp. 105–123. Springer (2012) 7. Franconi, E., Guagliardo, P.: The view update problem revisited. CoRR abs/1211.3016 (2012) 8. Guo, Y., Pan, Z., Heflin, J.: An Evaluation of Knowledge Base Systems for Large OWL Datasets. In: Proc. of the International Semantic Web Conference (ISWC). pp. 274–288 (2004) 9. Horridge, M., Bechhofer, S.: The OWL API: A Java API for OWL ontologies. Semantic Web 2(1), 11–21 (2011) 10. Horrocks, I., Li, L., Turi, D., Bechhofer, S.: The Instance Store: DL Reasoning with Large Numbers of Individuals. In: Haarslev, V., Möller, R. (eds.) Description Logics. CEUR Workshop Proceedings, vol. 104. CEUR-WS.org (2004) 11. Kiryakov, A., Ognyanov, D., Manov, D.: OWLIM - A Pragmatic Semantic Repos- itory for OWL. In: Dean, M., Guo, Y., Jun, W., Kaschek, R.H., Krishnaswamy, S., Pan, Z., Sheng, Q.Z. (eds.) WISE Workshops. Lecture Notes in Computer Science, vol. 3807, pp. 182–192. Springer (2005) 12. Laallam, F.Z., Kherfi, M.L., Benslimane, S.M.: A survey on the complementarity between database and ontologies: principles and research areas. IJCAT 49(2), 166– 187 (2014) 13. Pan, Z., Heflin, J.: DLDB: Extending Relational Databases to Support Semantic Web Queries. In: In PSSS. pp. 109–113 (2003) 14. Pease, A., Schulz, S.: Knowledge Engineering for Large Ontologies with Sigma KEE 3.0. In: Demri, S., Kapur, D., Weidenbach, C. (eds.) IJCAR. Lecture Notes in Computer Science, vol. 8562, pp. 519–525. Springer (2014) 15. Roldán Garcı́a, M., Aldana Montes, J.: Evaluating DBOWL: A Non-materializing OWL Reasoner based on Relational Database Technology. In: Horrocks, I., Yatske- vich, M., Jiménez-Ruiz, E. (eds.) ORE. CEUR Workshop Proceedings, vol. 858. CEUR-WS.org (2012) 16. Tsarkov, D., Palmisano, I.: Chainsaw: a metareasoner for large ontologies. In: Hor- rocks, I., Yatskevich, M., Jiménez-Ruiz, E. (eds.) ORE. CEUR Workshop Proceed- ings, vol. 858. CEUR-WS.org (2012) 17. Zhou, J., Ma, L., Liu, Q., Zhang, L., Yu, Y., Pan, Y.: Minerva: A Scalable OWL Ontology Storage and Inference System. In: ASWC. pp. 429–443 (2006)