In contexts where knowledge should be semantically well-de ned for computational processing, the development and use of ontologies has been increasing. An example are the Geographical Information Systems. This work presents a semi-automatic method to generate a geographic ontology from heterogeneous geographical information sources such as Geonames, OpenStreetMap and spatial databases. The proposed approach begins with a preliminary ontology, which is enhanced and extended from the prior sources along with the automatic generation of spatial relationships. The main contribution of this work is the integration of several geographic information sources into an OWL2-ontology, together with di erent mechanisms developed for its management. Several experiments were performed on the speci c region of Cuba, as well as functional testing through di erent queries; some of them are shown as examples.
Segun se ha reportado, aproximadamente el 80 % de la informacion en
formato electronico actualmente almacenada, se corresponde con informacion
georreferenciada o susceptible de serlo [
Por otra parte, el desarrollo de Internet y la interconectividad global ha
propiciado el surgimiento de grandes fuentes de informacion generadas por los
usuarios, conocidas en el ambito espacial como Informacion Geogra ca
Voluntaria (VGI). Dos de las mas abarcadoras en este contexto son Geonames4 y
OpenStreetMap5 (OSM). Geonames es una base de datos geogra ca que cubre
todos los pa ses y contiene mas de ocho millones de nombres de lugares. La
informacion esta organizada en nueve clases, conocidas como featureClass, donde
cada una cuenta con un grupo de codigos para clasi car la informacion
contenida. OSM es un proyecto de colaboracion para crear un mapa del mundo que
sea editable por los usuarios, inspirado en Wikipedia, pero en lugar de art culos
los usuarios editan entidades geogra cas (Nodes, Ways y Relations ). Por otra
parte, tambien se encuentran las Bases de Datos Espaciales (BDE), las cuales
constituyen un tipo de base de datos donde se describen objetos espaciales a
traves de tres caracter sticas basicas: atributos, localizacion y topolog a [
En este trabajo se propone un metodo para la construccion semi-automatica de una ontolog a geogra ca en la que se integrara informacion proveniente de Geonames, OSM y BDE. El metodo parte de la construccion manual de una ontolog a preliminar del dominio geogra co usando Protege, en la que se representan conceptos, propiedades y relaciones espaciales comunes, e incluye mecanismos de extension de esta ontolog a a partir de cada una de las fuentes de informacion, dividido en tres fases, as como un proceso nal de generacion automatica de relaciones espaciales. Como resultado se obtiene una ontolog a geogra ca codi cada en OWL2. Este disen~o se ha concebido como un proceso de desarrollo de la ontolog a de manera iterativa e incremental, y no partiendo de cero, sino tomando de referencia informacion existente en otras ontolog as geogra cas, as como de los propios recursos mencionados. La ontolog a geogra ca resultante sera utilizada en un sistema de RIG, con el objetivo de mejorar la precision de sus resultados e incrementar la satisfaccion de los usuarios. 2.
En la literatura revisada existen varios trabajos que abordan el problema de
la generacion semiautomatica de ontolog as a partir de bases de datos [
La vinculacion de datos geoespaciales desde sistemas de informacion heterogeneos ha sido abordado previamente en el proyecto GeoKnow7, siendo uno de los resultados mas relevantes la obtencion del LinkedGeoData (representacion en RDF de OpenStreetMap). En este proyecto los procesos de extraccion y administracion de informacion geoespacial se llevan a cabo a partir del tratamiento de tripletas RDF y no a traves de la construccion de ontolog as geogra cas codi cadas en lenguaje OWL2, lo cual limita las posibilidades de descripcion semantica de esta informacion y con ello la generacion de nuevo conocimiento. Sin embargo, al ser un proyecto generico, que no se centra en ninguna fuente de datos espec ca, se ha considerado que existe un margen de mejora si se profundiza en las caracter sticas particulares de cada conjunto de datos en el momento de la integracion.
En [
En [
El metodo propuesto se inicia con la construccion manual de una ontolog a preliminar del dominio geogra co en que se representan conceptos, propiedades y relaciones espaciales comunes en este dominio. Luego se ejecutan secuencialmente en tres fases mecanismos de extension de esta ontolog a usando Geonames, OSM y BDE. Estos procesos incluyen tareas de extraccion de conceptos, relaciones e individuos desde cada fuente. Al nal, se lleva a cabo un proceso de generacion automatica de relaciones espaciales, obteniendose como resultado la ontolog a geogra ca codi cada en OWL2 en la cual se integra informacion proveniente de las tres fuentes mencionadas. La Figura 1 esquematiza el ujo de trabajo del metodo.
Teniendo en cuenta el volumen de informacion a ser integrada en la ontolog a resultante, y para reducir el consumo de memoria RAM a la hora de procesar esta ontolog a se disen~o una clase espec ca llamada Ontology, capaz de administrar ontolog as con un gran numero de individuos y propiedades, y de obtener informacion de ella sin la necesidad de utilizar razonadores. En esta clase se implementaron funcionalidades que sustituyen a los razonadores en la generacion de conocimiento, por ejemplo, para recuperar las subclases e instancias de una clase espec ca, as como las clases equivalentes, dando la posibilidad de almacenar los valores de las propiedades en una base de datos disen~ada para esa tarea y no en el chero ontologico, y con ello reducir el consumo de memoria en el procesamiento de la ontolog a. La gestion de la ontolog a en las diferentes fases se hizo con la version 4.1.4 del framework OWLAPI, un framework Java disen~ado
coordinates
Figura 1. Etapas fundamentales del proceso de generacion de la ontolog a para gestionar ontolog as en OWL2. Protege 4, el editor de ontolog a de codigo abierto mas popular, por ejemplo, esta construido alrededor de OWLAPI. 3.1.
En este proceso se lleva a cabo la construccion manual de una ontolog a
preliminar del dominio geogra co en la cual se representan conceptos, propiedades
y relaciones espaciales comunes dentro de este dominio. En la construccion de la
conceptualizacion de esta ontolog a se utilizo como referencia fundamental
Geonames, la cual posee un elevado nivel de aplicabilidad y constituye una fuente de
datos geogra cos bien documentada y extensa, cuyo vocabulario basico
constituye un buen punto de partida para de nir una ontolog a del dominio geogra co.
Espec camente, se utilizo la ontolog a GeonamesOntology10, desde donde
fueron seleccionados conceptos basicos y propiedades de tipos de datos. Tambien
fueron representados en la ontolog a preliminar conceptos y propiedades
identi cadas en OSM, as como las propiedades de objetos (ej. 'esta al norte de',
'contiene', 'se superpone', 'intersecta con') que son comunes en el estado del arte
[
Las relaciones espaciales fueron modeladas de la misma forma que
normalmente se hace en la literatura especializada [
Figura 2. Taxonom a de conceptos de la ontolog a preliminar
esta ontolog a preliminar se llevo a cabo usando Protege, siguiendo la propuesta
metodologica reportada en [
Como resultado, se obtuvo una ontolog a formada por 15 clases, 14 relaciones taxonomicas, 15 propiedades de objeto (owl:ObjectProperty ) organizadas en una taxonom a y que representan relaciones semanticas entre las clases, as como 32 propiedades de tipo de dato (owl:DataTypeProperty ) tambien organizadas en una taxonom a, y se han incorporado 25 anotaciones. Tanto en las propiedades objeto como en las de tipo de datos estan especi cados en su dominio (rdfs:domain) todas las clases de nidas, brindando as capacidades para alcanzar un nivel alto de descripcion de los objetos espaciales que se representen en esta ontolog a. A partir de esta ontolog a preliminar el metodo propone la ejecucion de un proceso de extension a partir de Geonames, OSM y BDE, que se describen a continuacion. 3.2.
En esta primera fase, se lleva a cabo un proceso automatico de extension de la ontolog a preliminar, a partir de extraer toda la informacion posible de Geonames. Como parte de este proceso se extraen de la fuente espec ca nuevos conceptos a ser incorporados a la ontolog a preliminar, as como propiedades e individuos. Este proceso de extraccion de informacion es guiado por los individuos almacenados en Geonames, es decir, a partir de cada individuo se extraen todos los conceptos con los cuales esta relacionado, as como sus relaciones y propiedades. En correspondencia con la informacion descrita en Geonames, se extiende automaticamente la taxonom a de clases de la ontolog a preliminar. La extension incluye la propia descripcion (Annotations en OWL2) que aparece en Geonames para cada nueva clase. Se extrae informacion impl cita, evitando la utilizacion de razonadores para inferir conocimiento. Aqu tambien se identi can y eliminan toponimos ambiguos.
En esta investigacion dos toponimos seran considerados ambiguos si la distancia espacial entre sus dos puntos mas cercanos es menor que 1000 metros y sus nombres o nombres alternativos son sintacticamente similares segun la funcion de similitud Damerau-Levenshtein12. Con el objetivo de considerar la longitud de las cadenas a comparar, la funcion se utilizo de la siguiente forma: dos cadenas son similares si el resultado de la funcion es menor o igual que uno, cuando el promedio de las cadenas comparadas es menor o igual a siete, o menor o igual que dos cuando el promedio es mayor que siete. Esta modi cacion permite ajustar el impacto de las diferencias en las cadenas a comparar en correspondencia con la longitud de las mismas, no es lo mismo una distancia de uno en cadenas de longitud cuatro que en cadenas de longitud 30. La fundamentacion del uso de la funcion de similitud Damerau-Levenshtein esta basada en que dos de las fuentes de datos utilizadas en esta investigacion son construidas de manera voluntaria por los humanos, por tal motivo los errores tipogra cos tienen mayor probabilidad de aparecer en comparacion con otros tipos de errores. Cabe sen~alar que no todos los toponimos de Geonames tienen un boundingBox de nido, para lo cual se construye la cadena WKT a partir de las coordenadas geogra cas del punto que identi ca al objeto. Por el contrario, para los casos que tienen de nida la propiedad boundingBox, la cadena WKT es construida a partir de las coordenadas de los cuatro puntos que de nen el propio boundingBox. Para acceder a los recursos de Geonames se utilizo la biblioteca de Java geonames-1.1.1313, la cual garantiza acceso pleno a los recursos de Geonames a traves de servicios web desde el lenguaje de programacion Java. 3.3.
Una vez que la ontolog a preliminar ha sido enriquecida con la informacion
de Geonames, en esta segunda fase se extrae de manera automatica toda la
informacion posible de OSM. De forma analoga al proceso anterior, tambien se
identi can en esta fuente conceptos, propiedades e individuos a ser incorporados
a la ontolog a en construccion, igualmente guiado por estos ultimos. En
correspondencia con la informacion descrita en [
El algoritmo de extension usando OSM que se ha aplicado se muestra a continuacion: 12 https://en.wikipedia.org/wiki/Damerau-Levenshtein_distance 13 http://www.geonames.org/source-code Ontology ExtensionOSM(Ontology ontology){
int cantObject= ontology.cantObjetosOSMPertenecientesZona Geografica(); for i = 1 to cantObject hacer {
Tnode objetoEspacial = ontology.ObtenerObjetoEspacial(i); if (InfoValida(objetoEspacial)){ string typeClass = identificarClase(objetoEspacial); ontology.WriteToponymInOntology(objetoEspacial); switch (typeClass){ case "type1":
AnalizarCorrespondenciaConClasesDeOntolog aEn Construccion(typeClass);
BuscaryDefinirIndividuosAmbiguos(objetoEspacial,
listClases_a_Comparar(typeClass)); break; case "typeN":
AnalizarCorrespondenciaConClasesDeOntolog aEn Construccion(typeClass);
BuscaryDefinirIndividuosAmbiguos(objetoEspacial,
listClases_a_Comparar(typeClass)); break; }
} } } return ontology;
InfoEsValida(objetoEspacial ): de ne si la informacion presente en objetoEspacial es valida o no.
Identi carClase(objetoEspacial ): identi ca la clase presente en la ontolog a a la cual debe pertenecer el objeto espacial objetoEspacial o de ne una nueva clase para el.
AnalizarCorrespondenciaConClasesDeOntolog aEnConstruccion (typeClass): identi ca la clase typeClass en la ontolog a o construye una nueva clase. En caso de construir una nueva clase, la ubica en la taxonom a de la ontolog a y de ne un comentario o Annotations para esa nueva clase.
listClases a Comparar(typeClass): obtiene el listado de clases presentes en la ontolog a que pudieran tener individuos ambiguos al objeto espacial que se esta analizando.
la ontolog a y los de ne como similares.
Por ultimo, la gestion de los recursos disponibles en OSM se hizo a traves de la biblioteca Java osm4j 14, la cual brinda varias ventajas si la comparamos con sus homologas mas conocidas como Osmosis15. 14 http://www.topobyte.de/projects/osm4j 15 http://wiki.openstreetmap.org/wiki/Osmosis
El objetivo de esta fase es extraer toda la informacion posible de una BDE que este al menos en Primera Forma Normal, e incorporarla a la ontolog a en construccion, tambien tratando la ambiguedad de individuos y clases. El mecanismo de nido posibilita obtener informacion e integrarla a la ontolog a proveniente de cualquier BDE. Se propone para la integracion de informacion proveniente de una BDE la utilizacion de la cadena WKT como alternativa para representar en OWL2 el campo Geometry de los gestores de BDE. Todas las relaciones entre tablas se han modelado como relaciones funcionales del tipo \HasA", de nida en la ontolog a preliminar como una propiedad de objeto funcional. Por ultimo, tambien se ha llevado a cabo la traduccion a OWL2 de restricciones sobre atributos y tablas: condicion de Primera Forma Normal, NOT NULL, UNIQUE y PRIMARY KEY.
Toda la estructura organizativa de la BDE es generada automaticamente a partir del modelo f sico de la misma. El usuario nal solo pudiera intervenir para especi car por cada tabla que concepto de la ontolog a es equivalente al concepto asociado a la tabla y el nombre de la columna que representa el nombre de los objetos espaciales. Si este ultimo atributo no se suministra, se asume que es el campo llave y si no se suministra un concepto equivalente se asume que no existe. En este enriquecimiento es posible incorporar nuevas clases e individuos a la ontolog a, ademas de equivalencia entre clases, relaciones entre esos individuos, restricciones de datos y de objetos. Una vez ejecuta las reglas de mapeado entre los componentes de la BDE y la ontolog a en construccion, se analiza la posible ambiguedad de los individuos. Por cada nuevo individuo que este dentro del area geogra ca de interes, se buscan individuos ambiguos en la ontolog a, incluyendo los de la BDE. El algoritmo utilizado para buscar ambiguedades es similar al utilizado en las fuentes anteriores. Por ultimo, la gestion de la BDE se hace a partir del Java Database Connectivity(JDBC)-9.3-1104 de PostgreSQL16 y el 1.3.3 de PostGIS17 para administrar los datos espaciales. 3.5.
Una vez integradas en la ontolog a las tres fuentes de datos, se identi can todos los pares de individuos que cumplen con alguna de las propiedades de objetos de nidas en la ontolog a preliminar, las cuales representan relaciones espaciales. Esta informacion es almacenada en una base de datos y no en el chero OWL, usando la clase Ontology descrita anteriormente. En este proceso se aprovecha la integracion de informacion realizada en la ontolog a al culminar las tres fases anteriores, en el cual todos los individuos tienen su geometr a en un mismo formato: cadena WKT. Al igual que en la extension desde Geonames, este modulo es capaz de identi car todos los pares de individuos que cumplen 16 http://www.postgresql.org 17 http://postgis.net 1ra 2da 3ra fase fase fase
Clases 667 699 723
Clases equivalentes 0 1 11 Relaciones taxonomicas o subclases 682 749 956
Individuos 47 5.863 8.158 Rel. de objeto entre pares de individuos 264 264 264
Prop. de datos con valor en individuos 1.316 48.343 105.054
Pares de individuos similares 1 1.216 2.115
Anotaciones 696 728 728
Generacion de Rel. Esp.
27.763.887
12.217 Tabla 1. Resultado de la extension de la ontolog a preliminar para el municipio Marianao (La Habana) con alguna de las propiedades de objeto de nidas en la ontolog a preliminar, sin importar que algunos puedan ser generados posteriormente por los razonadores. Para ello, se apoya en la biblioteca ESRI JAVA Geometry18. 4.
A partir de la ontolog a preliminar construida se realizaron pruebas de los procesos de extension de nidos en el metodo. Las pruebas se realizaron mediante la ejecucion de esos procesos sobre las fuentes seleccionadas, pero considerando solo informacion relacionada con una region de Cuba, espec camente la del municipio de Mariano de la provincia de La Habana. No obstante, el metodo esta disen~ado para procesar informacion relacionada con cualquier area geogra ca sobre la que se almacene informacion en las fuentes. En la Tabla 1 se muestra como la ontolog a se va enriqueciendo con la ejecucion de los diferentes procesos, obteniendose al nal un recurso ontologico con un gran volumen de informacion representada; sobre todo muy enriquecido en cuanto a individuos y relaciones semanticas entre ellos. Esto alcanza especial relevancia teniendo en cuenta el proposito de esta ontolog a (fuente primaria de informacion en un sistema de RIG) ya que mientras mas informacion sea representada, el sistema de RIG tendra mayores capacidades para satisfacer las necesidades de informacion de los usuarios. La inclusion de 728 anotaciones con informacion descriptiva y complementaria de los elementos representados tambien es otro aspecto relevante porque facilita el uso de este recurso y, ademas, esta informacion tambien puede ser suministrada a los usuarios como resultado de la RIG.
Adicionalmente, se realizaron pruebas de funcionalidad teniendo en cuenta el proposito de esta ontolog a. En este sentido, se realizaron 50 consultas sobre la ontolog a dirigidas a recuperar informacion referente a objetos espaciales (ej. toponimos), con resultados satisfactorios. En la Tabla 2 se muestran los resultados de cuatro consultas realizadas, las cuales se formalizan mediante la terna: 18 http://github.com/Esri/geometry-api-java/wiki Q1 Q2 Q3 Q4 Id Requisito de informacion
Recursos hidrogra cos en Marianao Calles que cruzan la localidad de \Los Pocitos"
Objetos espaciales en \Los Pocitos"
Objetos espaciales en un radio de
3 kms del Hospital Infantil \Juan Manuel
Marquez" fuente, identi cador (en la fuente), nombre del objeto; en el caso de la BDE, los dos ultimos elementos de la terna se convierten en uno. En los resultados de cada consulta se puede apreciar como la informacion recuperada proviene de diferentes fuentes, como intervienen varias clases de la ontolog a en la obtencion de la respuesta, y el requisito de informacion.
Por ultimo, cabe resen~ar que dadas las caracter sticas de la geontolog a obtenida donde la informacion no esta ntegramente en el chero OWL, no fue posible utilizar SPARQL como lenguaje de consultas, utilizandose en su lugar los metodos de razonamiento implementados.
En este trabajo se describe un metodo computacional para generar, de manera semiautomatica, una ontolog a geogra ca que conceptualiza cualquier zona geogra ca del mundo con el objetivo de ser utilizada en un sistema de RIG. Los experimentos realizados sobre el municipio de Marianao (La Habana) evidencian que las caracter sticas de la ontolog a geogra ca resultante son idoneas para el exito de un futuro sistema de RIG sobre dicho municipio. Aunque solo se hicieron pruebas funcionales utilizando la ontolog a resultante, los resultados obtenidos demuestran el progreso de caracter sticas que de nen la evaluacion cualitativa de la ontolog a generada por cada una de las etapas de enriquecimiento y las consultas realizadas con rman el exito del proceso de RIG.
Este trabajo ha sido parcialmente nanciado por el Ministerio de Econom a y Competitividad del Gobierno de Espan~a, proyecto REDES (TIN2015-65136C2-1-R).