INTEGRACIÓN Y PUBLICACIÓN COMO “OPEN LINKED DATA” DE...

INTEGRACIÓN Y PUBLICACIÓN COMO “OPEN LINKED DATA” DE INFORMACIÓN GEOGRÁFICA

CATASTRAL A TRAVÉS DE ONTOLOGÍAS BAJO EL CONTEXTO DE LA WEB SEMÁNTICA

Fallon Andrea Flórez Galindo

Universidad Nacional de Colombia Facultad de Ciencias Agrarias, Escuela de Posgrado

Bogotá, Colombia 2015

INTEGRACIÓN Y PUBLICACIÓN COMO “OPEN LINKED DATA” DE INFORMACIÓN GEOGRÁFICA

CATASTRAL A TRAVÉS DE ONTOLOGÍAS BAJO EL CONTEXTO DE LA WEB SEMÁNTICA

Fallon Andrea Flórez Galindo

Tesis de investigación presentada como requisito parcial para optar al título de: Magister en Geomatica

Director (a): M.Sc., Jhonny Alexis Saavedra

Codirector (a): M.Sc., Alberto Boada Rodríguez

Línea de Investigación: Tecnologías Geoespaciales

Universidad Nacional de Colombia Facultad de Ciencias Agrarias, Escuela de Posgrado

Bogotá, Colombia 2015

Si supiese qué es lo que estoy haciendo, no le llamarían investigación, verdad?... La mente que se abre a una nueva idea, jamás volverá a su tamaño original. Albert Einstein

Agradecimientos

Agradezco primordialmente a Dios, quien es el promotor de todos los éxitos en las metas propuestas en el transcurso de mi formación académica y profesional. Agradezco los esfuerzos y la valiosa colaboración de mi Director y Co-Director de Tesis M.Sc. Jhonny Alexis Saavedra y M.Sc. Alberto Boada Rodríguez quienes depositaron sus valiosos conocimientos para abordar los desafíos al emprender el presente proyecto de investigación. A mis profesores de Maestría en Geomática de la Universidad Nacional de Colombia, quienes aportaron con sus enseñanzas en el contenido temático para llegar a feliz término el presente trabajo de grado. A mi familia quienes aportaron con su paciencia y toda su confianza para culminar satisfactoriamente este proyecto.

Resumen IX

Resumen

En un entorno general el catastro es comúnmente definido como una actividad sistemática que se encuentra orientada hacia un registro o inventario de la propiedad inmobiliaria a nivel regional. En función de generar dicho registro e inventario, éste se encuentra asociado a ciertos procesos que finalmente permiten describir la situación física, jurídica, económica y fiscal del bien inmueble. Incorporar dicho sistema catastral a un ámbito multifinalitario implica no solamente generar mayor calidad en los procesos y procedimientos habituales para garantizar la veracidad y precisión en los datos, además es necesario apuntar a la implementación de nuevas tecnologías informáticas que permitan potencializar la difusión y aprovechamiento de los datos en diversas disciplinas para generar mejores prácticas de planeación y ordenamiento territorial. Sin embargo, las diferencias estructurales y semánticas entre las bases de datos geográficas generadas por los catastros a nivel nacional, dificulta el intercambio y difusión de la información, debido a la autonomía que tienen las autoridades catastrales en cuanto a los procedimientos y metodologías internas para el uso, manejo, manipulación y difusión, ya que estas han generado sus propios modelos de datos geográficos catastrales diseñados y ajustados a sus propias necesidades limitando apuntar a un catastro multipropósito. La aplicación de redes de ontologías bajo el contexto de la web semántica en la integración de los modelos de datos geográficos catastrales, permite integrar datos catastrales con diferentes modelos y facilita su vinculación con otra información mediante su publicación como Open Linked Data. Esto con miras a mejorar las capacidades de la información geográfica catastral dispuesta en la web pensando en un catastro multipropósito. El presente proyecto de investigación presenta una solución en materia de integración de información geográfica catastral a partir de modelos de datos heterogéneos mediante el desarrollo de redes de ontologías y su publicación como “Open Linked Data” bajo los lineamientos de la Web Semántica.

Palabras clave: Web semántica, datos abiertos vinculados, redes de ontologías, integración y publicación, catastro multifinalitario, información geográfica catastral

XVII Integración y publicación como “Open Linked Data” de información geográfica catastral a

través de redes de ontologías bajo el contexto de la web semántica

Abstract

In a general environment “The Cadastre” is commonly defined as a systematic activity that is oriented to inventory of the property at regional level. In terms of generating such registration or inventory, it is associated with certain processes that finally allow to describe the physical, legal, economic and fiscal situation of the property. Incorporate this cadastral systems to multipurpose field, involves not only generate higher quality processes and standard procedures to ensure the accuracy and precision of the data, also is necessary to point to the implementation of new computer technologies to potentiate the dissemination and use of data in various disciplines to generate best practices and land use planning. However, structural and semantic differences between geographic databases generated by cadastral national, difficult the exchange and publication of information, because cadastral authorities have autonomy in internal procedures and methodologies for the use, management, manipulation and publication because they have created their own models of cadastral geographic data designed to their own needs limiting generate a multipurpose cadastre

Applying ontology networks in the context of the semantic web in the integration of cadastral geographical data models, can integrate cadastral data with different models and facilitates links with other information by publication as Linked Open Data. This to improve the capabilities of the cadastral geographic information provided on the web oriented multipurpose cadastre. This research project makes the cadastral geographic information integration from heterogeneous data models and the development of ontology networks and publication as "Open Linked Data" under the guidelines of the Semantic Web. Keywords: Semantic web, open linked data, ontology networks, integration and publication, multipurpose cadastre, cadastral geographic information

Contenido XI

Contenido

Resumen ........................................................................................................................ IX

Lista de figuras ............................................................................................................ XIV

Lista de tablas ............................................................................................................ XVII

Introducción .................................................................................................................. 19

1. CAPÍTULO I: MARCO TEÓRICO Y CONCEPTUAL................................................ 23 1.1 Contexto de la información geoespacial ........................................................... 23

1.1.1 La información geográfica .............................................................................. 23 1.1.2 Catálogo de Objetos ...................................................................................... 24 1.1.3 Modelo de datos: ........................................................................................... 26 1.1.4 Portales y servicios geográficos en la web ..................................................... 27

1.2 Web Semántica ................................................................................................ 29 1.2.1 Evolución de la web ....................................................................................... 30 1.2.2 Componentes Web Semántica: ..................................................................... 31 1.2.3 Open Linked Data .......................................................................................... 31 1.2.4 Integración e interoperabilidad de datos heterogéneos .................................. 33 1.2.5 Ontologías ..................................................................................................... 35

1.3 El catastro predial............................................................................................. 36 1.3.1 Objetivos Generales del Catastro: ................................................................. 37 1.3.2 El catastro multifinalitario ............................................................................... 38 1.3.3 Estructura del Catastro Nacional ................................................................... 39 1.3.4 Modelos de Datos Catastrales Nacionales ..................................................... 40 1.3.5 Número Predial Nacional ............................................................................... 41 1.3.6 Caracterización de los Servicios Web para el Catastro .................................. 42

2. CAPÍTULO II: PLANTEAMIENTO ........................................................................... 45 2.1 Objetivos .......................................................................................................... 45

2.1.1 Objetivo General: ........................................................................................... 45 2.1.2 Objetivos Específicos:.................................................................................... 45

2.2 Alcance ............................................................................................................ 46 2.3 Metodología ..................................................................................................... 46

2.3.1 Fase de Iniciación: ......................................................................................... 48 2.3.2 Fase de Análisis y Diseño: ............................................................................. 49 2.3.3 Fase de Construcción: ................................................................................... 50

3. CAPÍTULO III: ANÁLISIS DE FUENTES Y DISEÑO GENERAL DEL SISTEMA .... 51 3.1 Análisis de Fuentes .......................................................................................... 51

3.1.1 Revisión de fuentes y modelos internacionales.............................................. 51 3.1.2 Lenguajes y Tecnologías que sustentan la Web Semántica .......................... 61 Componentes de la arquitectura general de la web semántica “Semantic Web Stack” 62 3.1.3 Recursos ontológicos y no ontológicos (modelos y vocabularios) .................. 64 3.1.4 Datos potencialmente vinculables .................................................................. 66

3.2 Diseño General del Sistema ............................................................................. 67 3.2.1 Tecnologías de implementación disponibles: ................................................. 67



3.3 Resumen de componentes de arquitectura utilizados: ...................................... 70

3.3.1 Diagrama de arquitectura del sistema ........................................................... 71 3.3.2 Componentes de arquitectura para el análisis y modelamiento de los datos catastrales: .............................................................................................................. 72 3.3.3 Componentes de arquitectura para la integración de los modelos de datos catastrales: .............................................................................................................. 72 3.3.4 Componentes de arquitectura para la generación de datos en formato RDF: 72 3.3.5 Componentes de arquitectura para el repositorio de los datos en formato RDF: 73 3.3.6 Componentes de arquitectura para la configuración del sistema de publicación y vinculación de datos .............................................................................................. 73 3.3.7 Características técnicas del servidor ............................................................. 74

4. CAPÍTULO IV: DISEÑO Y MODELAMIENTO DE DATOS ...................................... 75 4.1 Modelo De Datos Catastral Nacional - IGAC ..................................................... 75

4.1.1 Generalidades ............................................................................................... 75 4.1.2 Catálogo de Objetos – IGAC (ICDE) ............................................................. 77 4.1.3 Estructura General del Modelo de Datos Catastral Nacional – IGAC ............. 79

4.2 Modelo de Datos Catastral de Bogotá - UAECD ............................................... 84 4.2.1 Generalidades ............................................................................................... 84 4.2.2 Catálogo de Objetos del Mapa de Referencia ............................................... 84 4.2.3 Modelo de Datos del Mapa de Referencia ..................................................... 86

4.3 MODELO “Land Administration Domain Model” – LADM (ISO: 19152) ............. 92 4.3.1 Objetivos LADM: ........................................................................................... 92 4.3.2 Funciones LADM: .......................................................................................... 92 4.3.3 Características de LADM: .............................................................................. 93 4.3.4 Clases Básicas LADM: .................................................................................. 93 4.3.5 Paquetes LADM: ........................................................................................... 94

4.4 Especificación de alcance ................................................................................. 97 4.4.1 Tipos de datos: .............................................................................................. 97 4.4.2 Extensión geográfica: .................................................................................... 97 4.4.3 Metadatos ..................................................................................................... 99 4.4.4 Usuarios Potenciales: .................................................................................. 100

4.5 Análisis de modelos de datos.......................................................................... 101 4.5.1 Diferencias modelo de datos catastral Nacional y Distrital: .......................... 102

4.6 Modelado LADM_CO ...................................................................................... 103 4.6.1 Catálogo de Objetos LADM_CO .................................................................. 104

5. CAPÍTULO V: DESARROLLO DE ONTOLOGÍAS ................................................ 105 5.1 Desarrollo de Ontologías ................................................................................ 105

5.1.1 Especificación de requerimientos ................................................................ 106 5.1.2 Conceptualización y formulación ................................................................. 106 5.1.3 Formalización y planeación ......................................................................... 108 5.1.4 Implementación y desarrollo de las ontologías: ........................................... 110

5.2 Construcción de Red de Ontologías:............................................................... 126 5.2.1 Proceso de homologación ........................................................................... 127 5.2.2 Asociación de ontologías al resultado de la homologación: ......................... 130

5.3 Depuración iterativa de la ontología: ............................................................... 133

6. CAPÍTULO VI: GENERACIÓN DE DATOS, PUBLICACIÓN Y VINCULACIÓN .... 134 6.1 Generación de datos ....................................................................................... 134

Contenido XIII

6.1.1 Especificación de requerimientos ................................................................ 134 6.1.2 Diagrama del proceso de generación de datos: ........................................... 135 6.1.3 Patrón de URIs de los datos ........................................................................ 136 6.1.4 Conversión de datos a formato RDF ............................................................ 136 6.1.5 Depuración de datos en formato RDF .......................................................... 139

6.2 Publicación de datos .......................................................................................139 6.2.1 Publicación Componente Alfanumérico: ...................................................... 140 6.2.2 Publicación Componente Espacial: .............................................................. 142

6.3 Vinculación de Datos .......................................................................................144 6.3.1 Creación del Proyecto de Vinculación “WorkSpace” .................................... 146 6.3.2 Fuentes de Datos ........................................................................................ 147 6.3.3 Generando Vínculos .................................................................................... 151

7. Conclusiones y Recomendaciones ..................................................................... 158 7.1.1 Productos derivados de la Investigación ...................................................... 158 7.1.2 Conclusiones ............................................................................................... 160 7.1.3 Recomendaciones y líneas futuras de investigación .................................... 161

Contenido XIV

Lista de figuras

Pág. Figura 1-1: Evolución de la información geográfica .................................................. 24

Figura 1-2: Componentes del Catálogo de Objetos .................................................. 25

Figura 1-3: Difusión y Acceso a la IG - Geoportales ................................................. 27

Figura 1-4: Web Service de OGC – Normas de Geoprocesamiento ......................... 28

Figura 1-5: Evolución de la web ............................................................................... 30

Figura 1-6: Tripleta funcionamiento RDF .................................................................. 32

Figura 1-7: La web actual vs la web semántica ........................................................ 33

Figura 1-8: La Visión de la Evolución del Catastro ................................................... 38

Figura 1-9: Esquema Organizacional del Sistema Catastral Nacional ...................... 40

Figura 1-10: Componentes del Número Predial Nacional ........................................... 42

Figura 1-11: Aplicación de consulta web de datos Catastrales - IGAC ....................... 43

Figura 1-12: Portal de Mapas de Bogotá .................................................................... 44

Figura 2-1: Fases y actividades en la metodología RUP .......................................... 46

Figura 2-2: Fases y etapas del proceso .................................................................... 47

Figura 3-1: Lenguajes y tecnologías básicas de la Web Semántica ......................... 61

Figura 3-2: Componentes de la arquitectura de la Web Semántica .......................... 63

Figura 3-3: Arquitectura general de Parliament ........................................................ 69

Figura 3-4: Diagrama de arquitectura ....................................................................... 71

Figura 4-1: Temas del Catálogo de Objetos ............................................................. 78

Figura 4-2: Grupos del tema Catastro - Catálogo de Objetos ................................... 78

Figura 4-3: Objetos del grupo Área Catastral - Catálogo de Objetos ........................ 79

Figura 4-4: Asociación objetos área urbana – Modelo Datos Catastral Nacional ...... 80

Figura 4-5: Asociaciones objetos área rural – Modelo Datos Catastral Nacional ...... 80

Figura 4-6: Atributos objetos área urbana – Modelo Datos Catastral Nacional ......... 81

Figura 4-7: Atributos objetos área rural – Modelo Datos Catastral Nacional ............. 82

Figura 4-8: Temas catálogo de objetos Mapa de Referencia de Bogotá ................... 85

Figura 4-9: Grupos catálogo de objetos Mapa de Referencia de Bogotá .................. 85

Figura 4-10: Objetos catálogo de objetos Mapa de Referencia de Bogotá ................. 85

Figura 4-11: Paquetes de LADM y sus clases ............................................................ 94

Figura 4-12: Clases del paquete Spatial Unit ............................................................. 95

Figura 4-13: Detalle de clases y relaciones paquete Spatial Unit ............................... 96

Figura 4-14: Sub-conjunto de datos catastrales ......................................................... 98

Figura 4-15: Metadato mapa de referencia de Bogotá ................................................ 99

Figura 4-16: Metadato mapa catastral digital urbano municipio de Soacha .............. 100

Contenido XV

Figura 4-17: Diferencias modelos de datos catastral Nacional y Distrital ..................101

Figura 4-18: UML con modelo conceptual de la Ontología “LADM_CO” ...................103

Figura 5-1: Flujo para el desarrollo y gestión de ontologías (NeOn Metodology) ....105

Figura 5-2: Fases desarrollo de ontologías para los escenarios contemplados ......108

Figura 5-3: Planeación para el desarrollo de ontologías (NeOn Toolkit) _Parte 1 ...108

Figura 5-4: Planeación para el desarrollo de ontologías (NeOn Toolkit) _Parte 2 ...109

Figura 5-5: Definición de la Clase Terreno Urbano: ................................................111

Figura 5-6: Propiedades y relaciones de la Clase Terreno Urbano: ........................112

Figura 5-7: Atributos de las clases: .........................................................................113

Figura 5-8: Propiedades de los Atributos ................................................................114

Figura 5-9: Relaciones entre las clases de la ontología: .........................................115

Figura 5-10: Relación “está formado por” entre las clases modelo nacional: ............115

Figura 5-11: Relación “es parte de” entre las clases modelo nacional: .....................116

Figura 5-12: Relación “pertenece a” entre las clases modelo nacional: ....................116

Figura 5-13: Relación “tiene” entre las clases modelo nacional: ...............................117

Figura 5-14: Esquema de Ontología Modelo de Datos Catastral Nacional: ...............118

Figura 5-15: Definición de la Clase Lote: ..................................................................119

Figura 5-16: Propiedades y relaciones de la Clase Lote: ..........................................120

Figura 5-17: Atributos de la Clase Lote: ....................................................................121

Figura 5-18: Propiedades Atributos de la Clase Lote: ...............................................121

Figura 5-19: Relación “está formado por” entre las clases del modelo distrital: .........122

Figura 5-20: Relación “es parte de” entre las clases del modelo distrital: ..................122

Figura 5-21: Relación “pertenece a” entre las clases del modelo distrital: .................123

Figura 5-22: Relación “tiene” entre las clases del modelo distrital: ............................123

Figura 5-23: Esquema de Ontología Modelo de Datos Catastral Distrital: .................124

Figura 5-24: Modelado UML LAMD_CO ...................................................................124

Figura 5-25: Clases del Modelo LADM_CO ..............................................................125

Figura 5-26: Atributos, dominios y tipos de datos Modelo LADM_CO .......................125

Figura 5-27: Relaciones Ontología Modelo LADM_CO .............................................126

Figura 5-28: Relaciones SubClase “Terreno” ............................................................126

Figura 5-29: LAMD_CO: Importación Ontologías Catastral Nacional y Distrital ........128

Figura 5-30: Ejemplo de equivalencias homologación del modelo LADM_CO ↔

IGAC/UAECD 128

Figura 5-31: Visualización Gráfica de la Clase “Address” .........................................129

Figura 5-32: Equivalencias de atributos ....................................................................129

Figura 5-33: Recursos asociados a la Ontología GeoSPARQL ................................130

Figura 5-34: Ontología GeoCOL ...............................................................................131

Figura 5-35: Asociación geoSPARQL a la ontología mapping ..................................132

Figura 5-36: Construcción de la Red de Ontologías ..................................................132

Figura 6-1: Diagrama del proceso de conversión de datos a formato RDF ............135

Figura 6-2: Esquema RDF componente alfanumérico Clase “Terreno Urbano” ......137

Figura 6-3: Salida RDF componente alfanumérico Clase “Terreno Urbano” ...........137

Figura 6-4: Esquema RDF componente espacial Clase “Terreno Urbano” .............138

Figura 6-5: Salida RDF componente espacial Clase “Terreno Urbano” ...................138



Figura 6-6: Interfaz del Triple Store Parliament 2015 ............................................. 139

Figura 6-7: Insertando datos componente alfanumérico Clase “Terreno Urbano” ... 140

Figura 6-8: Tripleta RDF ........................................................................................ 141

Figura 6-9: Tripleta RDF Componente Alfanumérico Clase Terreno Urbano .......... 141

Figura 6-10: Tripleta RDF Componente Alfanumérico Terreno =

“257540104000000020027000000000”. ....................................................................... 142

Figura 6-11: Insertando datos componente espacial Clase “Terreno Urbano” .......... 142

Figura 6-12: Tripleta RDF Componente Espacial Clase Terreno Urbano ................. 143

Figura 6-13: Publicación tripleta RDF Componente Espacial Terreno ...................... 143

Figura 6-14: Publicación tripleta RDF Componente Espacial Terreno ...................... 144

Figura 6-15: Vinculación de datos catastrales con otros datos ................................. 145

Figura 6-16: Proceso de Vinculación ........................................................................ 145

Figura 6-17: Creación del espacio de trabajo “Workspace” ...................................... 146

Figura 6-18: Propiedades de Vinculación Fuente de Datos Geográfica Catastral

“GeoCatastro” 146

Figura 6-19: Creación de Datasets para fuente de datos.......................................... 147

Figura 6-19: Propiedades de Vinculación Fuente de Datos DBpedia........................ 148

Figura 6-20: Recursos asociados a las fuentes de datos a vincular ......................... 149

Figura 6-21: Propiedades de Vinculación Fuente de Datos GeoCOL ....................... 150

Figura 6-22: Recursos asociados a las fuentes de datos a vincular ......................... 151

Figura 6-24: Relación de contenencia “Sitios Interés” (DBpedia) → “Terreno/Lote”

(IGAC/UAECD) 152

Figura 6-25: Enlazado datos catastrales ↔ DBpedia ............................................... 152

Figura 6-26: Propiedades de Vinculación ................................................................. 153

Figura 6-27: Link1: Geo Catastro - DBpedia ............................................................. 153

Figura 6-28: Visualización Gráfica de la Vinculación ................................................ 154

Figura 6-29: Homologación datos catastrales UPerimetro ↔ GeoCOL .................... 155

Figura 6-30: Enlazado datos catastrales ↔ GeoCOL ............................................... 155

Figura 6-31: Propiedades de Vinculación ................................................................. 156

Figura 6-32: Link2: GeoCatastro – GeoCOL ............................................................. 156

Figura 6-33: Publicaciones Linked Open Data .......................................................... 157

Contenido XVII

Lista de tablas

Pág.

Tabla 2-1: Actividades Fase de Iniciación .................................................................. 48

Tabla 2-2: Actividades Fase de Análisis y Diseño ...................................................... 49

Tabla 2-3: Actividades Fase de Construcción ............................................................ 50

Tabla 3-1: Representación Espacial de Condominio y Co-Propiedad......................... 52

Tabla 3-2: Modelo LADM/STDM: Visión para el 2025 ................................................ 52

Tabla 3-3: Proyecto Norma ISO TC 211 19 152 sobre Modelo Catastral ................... 53

Tabla 3-4: Modelo de datos de parcelas “INSPIRE” ................................................... 53

Tabla 3-5: Core Cadastre Domain Model (CCDM) ..................................................... 53

Tabla 3-6: Registro de la Propiedad Linked Open Data ............................................. 54

Tabla 3-7: Metodología basada en LADM, STDM, INSPIRE ...................................... 55

Tabla 3-8: Aspecto Legal y Espacial LCDM ............................................................... 55

Tabla 3-9: Ontología Catastro Venezuela .................................................................... 56

Tabla 3-10: Metodología de integración basada en ontologías .................................... 56

Tabla 3-11: Conflación semántica ................................................................................ 57

Tabla 3-12: Red de ontología Santiago de Chile .......................................................... 57

Tabla 3-13: Metodología NeOn .................................................................................... 57

Tabla 3-14: Cómo publicar Linked data en la web ........................................................ 58

Tabla 3-15: GeoSPARQL: Caso aplicación división territorial y administrativa de

Colombia ........................................................................................................................ 58

Tabla 3-16: Metodología para publicar Linked Data España ........................................ 59

Tabla 3-17: Evaluación de calidad de datos publicados ............................................... 59

Tabla 3-18: GeoSPARQL y Parliament ........................................................................ 59

Tabla 3-19: Líneas de investigación de geo-semántica y proyección futura ................. 60

Tabla 3-20: Web Semántica, ontologías y linked data: “Nuevas tendencias para la

gestión de la información geográfica” ............................................................................. 60

Tabla 3-21: Características equipo entorno de pruebas y producción .......................... 74

Tabla 4-1: Estructura Sector Urbano/Rural:................................................................ 83

Tabla 4-2: Estructura Barrio Urbano: .......................................................................... 83

Tabla 4-3: Estructura Manzana/Vereda: ..................................................................... 83

Tabla 4-4: Estructura Terreno Urbano/Rural: ............................................................. 83



Tabla 4-5: Estructura Construcción Urbana/Rural: ...................................................... 83

Tabla 4-6: Estructura Unidad Urbana/Rural: ............................................................... 83

Tabla 4-7: Estructura Nomenclatura Domiciliaria Urbana/Rural: ................................. 84

Tabla 4-8: Estructura Zona Homogénea Física Urbana/Rural: .................................... 84

Tabla 4-9: Estructura Zona Homogénea Geoeconómica Urbana/Rural: ..................... 84

Tabla 4-10: Ficha objeto Sector Catastral ..................................................................... 86

Tabla 4-11: Ficha objeto Manzana ................................................................................ 87

Tabla 4-12: Ficha objeto Lote ....................................................................................... 88

Tabla 4-13: Ficha objeto Construcción.......................................................................... 89

Tabla 4-14: Ficha objeto Placa ..................................................................................... 89

Tabla 4-15: Ficha objeto Localidad ............................................................................... 91

Tabla 4-16: Ficha objeto Municipio ............................................................................... 91

Tabla 4-17: Relación subconjunto de datos catastrales: ................................................. 98

Tabla 5-1: Escenarios contemplados en la especificación de requerimientos ........... 107

Tabla 5-2: Detalle de actividades en cada fase de desarrollo de las ontologías ........ 109

Tabla 7-1: Productos derivados de la investigación Objetivo Específico 1 ................ 158




Introducción 19

Introducción

El ordenamiento territorial es una disciplina de gran interés para la humanidad, surge de la preocupación de tener la capacidad de afrontar los problemas derivados de la interacción del hombre con el espacio en el que habita; por esta razón, la planeación sobre el territorio se ha convertido en un mecanismo preventivo para evitar conflictos relacionados con el uso y administración del suelo y los recursos naturales. Para llegar a tener los elementos suficientes para la toma de decisiones respecto al territorio es necesario contar con un inventario detallado en el cual se evidencie la descripción física de éste permitiendo establecer su organización y la toma de decisiones frente al desarrollo territorial.

El catastro se entiende como un sistema de información en el que se dispone de la descripción del estado actual del espacio geográfico en el que habitamos en lo que respecta a la propiedad inmobiliaria. La descripción física del territorio que realiza hoy día el catastro busca ser útil en múltiples fines ya que la interacción de la información registrada en una base de datos catastral, con la información de diferentes entidades del orden nacional y municipal, permite generar mejores prácticas de planeación y ordenamiento territorial.

El catastro multifinalitario ha cobrado gran importancia en los últimos años constituyéndose en uno de los principales objetivos de las administraciones catastrales municipales, dicha situación se presenta principalmente, gracias a la conciencia que se ha tomado acerca de la reestructuración de los sistemas catastrales con una visión encaminada a un catastro multipropósito. La Federación Internacional de Agrimensores - FIG planteó una perspectiva del catastro de América Latina, resumido en 6 declaraciones que de ser aplicadas permitirían una aproximación más clara al denominado “catastro multifinalitario”, es de nuestro interés particular la declaración número 4, la cual indica que “el catastro manual será cosa del pasado, la tecnología geomática será la herramienta normal para el trabajo catastral, y se deberá aplicar tecnologías de la información modernas para la manipulación de los modelos de datos básicos catastrales1”.

Con el fin de obtener un catastro multifinalitario, se deben publicar y difundir datos catastrales de tal forma que sean útiles para múltiples fines; sin embargo para lograr la difusión e intercambio de la información existen algunos limitantes que impiden que la información sea integrada entre sí y con otras temáticas:

1 Una visión para un sistema catastral futuro – Grupo de Trabajo 1 de la Comisión 7 de la FIG (Federación Internacional de Agrimensores)



1. El Instituto Geográfico Agustín Codazzi - IGAC es la entidad oficialmente encargada

del catastro nacional y tiene como misión producir, proveer y divulgar información y conocimiento en esta temática. El IGAC es la entidad encargada de regular la gestión catastral de tal manera que brinde el apoyo a los procesos de planificación y desarrollo integral del país. Bajo los lineamientos legales y normativos establecidos por el IGAC a nivel nacional en materia de catastro, también se encuentran conformados los cuatro catastros descentralizados: La unidad administrativa especial de catastro distrital de Bogotá, La subsecretaría de despacho de catastro de Medellín, La dirección de sistemas de información y catastro de la gobernación de Antioquia y La subdirección de catastro municipal de Cali, cuyos objetivos y funciones no difieren de las establecidas a nivel nacional por la resolución 70 de 2011; sin embargo, debido a la autonomía que tienen éstas autoridades catastrales en cuanto a los procedimientos y metodologías internas aplicadas en el uso, manejo, manipulación, difusión e intercambio de datos, han generado sus propios modelos de datos, cada uno con la semántica particular para los objetos manejados en sus bases de datos catastrales, lo cual dificulta el intercambio y difusión de la información y sus posibilidades de integración pensando en hacer análisis de datos catastrales del orden nacional. Además, el objetivo número 3 del catastro nacional establecido en el artículo número 2 de la actual reglamentación catastral, la resolución 70 de 2011, indica como un mandato que “las bases de datos catastrales deben corresponder a un sistema catastral único integrado por las diferentes instituciones catastrales a nivel nacional2”. Este aspecto aunque se ha logrado normativamente en los aspectos más generales, existen diferencias en el manejo y manipulación detallada de los modelos de datos y por ende en los objetos que hacen parte de la información geográfica catastral de las diferentes autoridades catastrales nacionales. De esta forma, actualmente las oficinas encargadas del catastro nacional no cuentan con modelos de datos estandarizados que permitan difundir la información de forma homogénea.

2. Los datos catastrales se diseñan pensando en una temática en particular en la que

van a ser usados lo que hace difícil usarlos en otras evitando apuntar a un catastro multipropósito y a la integración de la información con otros datos.

3. Los modelos de datos, servicios y aplicaciones tienen restricciones de integración

debido a la heterogeneidad de sus sistemas y metodologías internas de trabajo. Del Universo de estándares existentes cada iniciativa escoge unos en particular, lo cual puede dificultar la integración de sus resultados en otros sistemas de mayor envergadura (Klien, 2009). A nivel Nacional aunque se han aplicado estándares bajo el control de la ICDE e IDECA en materia de difusión de datos no se han definido escenarios de integración con la semántica unificada para las entidades que gestionan la información geográfica y espacial.

2 Artículo 2 - Resolución 70 de 2011, Por la cual se reglamenta técnicamente la formación catastral, la actualización de la formación catastral y la conservación catastral.

Introducción 21

4. Los Sistemas de Información Geográfica – SIG permiten visualizar, efectuar

consultas, realizar análisis espaciales (como cálculo de rutas o distancias) e incluso editar los datos a través de la web. Sin embargo, la integración que proponen los SIG actuales se limitan a una integración de información a nivel gráfico, creando mapas que superponen varias capas de información que representan elementos de la realidad. Sin embargo, para lograr su integración es necesario poder vincular cualquier tipo de datos con su componente espacial y realizar análisis que tengan en cuenta los atributos de todos los tipos de objetos de manera integrada independientemente de la temática o disciplina aplicada.

5. Debido a la falta de estandarización y homogenización en el manejo de los datos,

es posible evidenciar redundancia de información en la web. Para el catastro nacional se dispone en la web de diversos servicios en múltiples páginas con información duplicada perteneciente a la misma temática.

6. Los formatos y tecnologías manejadas actualmente para la difusión e intercambio

de datos no permiten el fácil acceso a los mismos, en la mayoría de los casos es posible acceder a imágenes de la información, más no a los datos como tal, sin demostrar eficiencia ni uso por parte de los usuarios finales.

Las tecnologías de la información han permitido potencializar el uso y manejo de datos incluso con desarrollo de herramientas específicas para análisis y visualización de datos geo-espaciales. La resolución 70 de 2011, indica en sus consideraciones “Con las nuevas tecnologías se logra que la administración pública sea más eficiente y eficaz en el manejo de la información y, por tanto, la hace más confiable para el usuario. Lo cual genera la necesidad de establecer y adoptar un marco normativo que permita, en un contexto jurídicamente seguro el uso de la tecnología como un medio de intercambio de información y su aprovechamiento por parte de los usuarios y de las autoridades catastrales3”.

En la actualidad existen múltiples tecnologías aplicables al catastro inmobiliario, gracias a que éstas permiten establecer procesos que comprenden desde la captura, estructuración, edición, mantenimiento, actualización, análisis, interpretación y difusión de datos. Sin embargo el acelerado crecimiento tecnológico, la necesidad de intercambio de datos y de implementar herramientas que permitan la difusión e interacción de la información por diferentes entidades territoriales, nos obliga a buscar alternativas tecnológicas que permitan superar la problemática asociada la falta de estandarización y homogenización de los modelos de datos geográficos catastrales a nivel nacional y su vinculación con otra información relacionada.

La web semántica “es un conjunto de actividades desarrolladas en el seno de World Wide Web Consortium tendente a la creación de tecnologías para publicar datos legibles por aplicaciones informáticas. Se basa en la idea de añadir metadatos semánticos y ontológicos a la World Wide Web que describen el contenido, el significado y la relación de los datos. El objetivo es mejorar internet ampliando la interoperabilidad entre los

3 Resolución 70 de 2011

https://es.wikipedia.org/wiki/World_Wide_Web_Consortium

https://es.wikipedia.org/wiki/World_Wide_Web_Consortium

https://es.wikipedia.org/wiki/Metadato

https://es.wikipedia.org/wiki/Sem%C3%A1ntica

https://es.wikipedia.org/wiki/Ontolog%C3%ADa_%28Inform%C3%A1tica%29

https://es.wikipedia.org/wiki/World_Wide_Web

https://es.wikipedia.org/wiki/Interoperabilidad



sistemas informáticos usando agentes inteligentes que son programas en las computadoras que buscan información sin operadores humanos4”. La web semántica ha sido poco explorada en materia de investigación a nivel nacional, sin embargo otros países tales como Estados Unidos, El Reino Unido, Italia y España, han encontrado en ella una posible solución a la hora de realizar la publicación y visualización de bases de datos heterogéneas y vinculadas en la web con otros datos.

El concepto de integración de datos bajo el contexto de la web semántica busca dar solución a los problemas derivados de la des-estandarización y falta de unificación y homologación de los modelos de datos que manejan información geográfica a través del desarrollo de redes de ontologías. Por su parte, la implementación de Open Linked Data permite la publicación y vinculación de los datos con otros datos en la web.

Es así como este proyecto de investigación busca implementar los avances de la web semántica en datos geográficos catastrales de tal forma que permitan la integración de los modelos de datos geográficos catastrales, su generación y publicación como datos abiertos vinculados en la web, con el fin de potencializar el uso de la información catastral en múltiples aplicaciones relacionadas con la administración de la tierra.

4 Desarrollo Web, Lorenzana Medina Daniel Gilberto, 2012

Capítulo I 23

1. CAPÍTULO I: MARCO TEÓRICO Y CONCEPTUAL

El presente capítulo comprende un marco de referencia que permite al lector conocer más al detalle los conceptos técnicos de las temáticas abordaras en el proyecto. Inicialmente se hace énfasis en el contexto de la información geográfica; en el segundo apartado se revisa el marco conceptual de la web semántica, las ontologías y el linked open data, finalmente el catastro físico y su desarrollo en el ámbito Nacional.

1.1 Contexto de la información geoespacial

1.1.1 La información geográfica

Se entiende un dato como un conjunto de valores o elementos que utilizamos para representar algo; por ejemplo, el código predial puede corresponder a un simple número y por sí solo no tiene un significado, por lo cual es necesario interpretarlo. Al realizar la interpretación del dato, nos informa que ese simple número corresponde a la propiedad inmobiliaria que ocupa un espacio geográfico (x, y, z), que hace parte de un propietario específico y tiene unas características físicas que hacen que se diferencie de los demás número o códigos prediales. Así, hablamos de información cuando el dato cobra un significado a partir de una interpretación y puede usarse para llevar a cabo operaciones sobre él, que tengan relación con el significado.

El trabajo de los Sistemas de Información Geográfica (SIG) con los datos se encuentra enfocado a obtener toda la “información geográfica” posible contenida en ellos, ya que un dato puede esconder más información de la que se percibe a primera vista, y es con la interpretación del mismo que se puede obtener. La gestión y aprovechamiento de datos referenciados a un espacio geográfico ha crecido y evolucionado gracias al uso de las tecnologías de la información geográfica, el uso de los SIG, las infraestructuras de Datos Espaciales (IDE) e iniciativas privadas como Google Earth, NASA Worldwind, Open Street Map y GeoNames, ha permitido disponer datos y servicios geo-espaciales en la web (SDI, Recetario IDE), potencializando así, el uso de los datos geográficos por parte del público en general.



Figura 1-1: Evolución de la información geográfica Fuente: Propia

Hasta hace aproximadamente 30 años la información de la descripción física del territorio se plasmaba en un mapa en formato análogo, posteriormente gracias a los avances tecnológicos, se llevó esta información al formato digital a partir de la digitalización de datos vectoriales apoyados de software, esto proporcionó un medio de almacenamiento, visualización y análisis de información geográfica. Así, el SIG concebido como un sistema de hardware, software y procedimientos elaborados para facilitar la obtención, gestión, manipulación, análisis, modelado, representación y salida de datos espacialmente referenciados permiten resolver problemáticas complejas de planificación y gestión territorial (Palomino, 2009).

En los últimos años se ha incrementado significativamente la cantidad de datos espaciales y con esto nacen nuevos retos para su gestión, almacenamiento, manipulación, uso y difusión. Las distintas problemáticas surgen de una producción centrada en satisfacer las necesidades individuales de cada entidad productora de datos geográficos, ya que la heterogeneidad en las bases de datos dificultaba la difusión e intercambio entre las diferentes entidades, así surge la necesidad de modelar bases de datos a través de estándares que permitan gestionar, acceder, suministrar y fomentar el uso de datos espaciales. Los catálogos de objetos y modelos de datos permiten estandarizar el modelamiento de bases de datos espaciales.

1.1.2 Catálogo de Objetos

Para la documentación del presente apartado se tomó como fuente la información suministrada en la página de la Infraestructura Colombiana de Datos Espaciales – ICDE:

Capítulo I 25

Un catálogo de objetos puede ser definido como una primera aproximación a la representación abstracta y simplificada de la realidad. Es una estructura que organiza los tipos de objetos espaciales, sus definiciones y características; son la base de otras representaciones particulares de niveles de abstracción, como son los modelos de datos y las bases de datos geográficas; además promueven la difusión y uso de los datos geográficos. Los componentes del catálogo de objetos son:

Figura 1-2: Componentes del Catálogo de Objetos Fuente: http://www.icde.org.co/web/guest/estandares_catalogo

Temas: Ordenan de forma general los elementos y fenómenos que van a ser modelados por el catálogo de objetos.

Grupos: Son los subconjuntos de objetos que tienen características similares y que por esta razón pueden agruparse dentro de un tema. Muestran de un modo muy general los objetos que componen las temáticas del catálogo de objetos.

Objetos: Es la unidad fundamental de la información geográfica. Es una representación abstracta de un determinado elemento o fenómeno del mundo real, asociado a una con una localización espacial con características específicas que lo diferencian de otros objetos.

La determinación de objetos depende tanto de la información descrita en el catálogo como de su propósito y se compone de instancias y tipos:

- Instancias: Particularización de un objeto que tiene valores que lo diferencian de otros objetos de la misma índole.

- Tipos: es un conjunto de instancias que tienen características similares, pero a su vez tienen atributos propios que los hacen diferentes de los demás.

Atributos: Son las características propias e implícitas que describen a los objetos

geográficos y que pueden tomar valores individuales en cada instancia del objeto. Es la parte informativa de un objeto y le da todo lo necesario para tenerlo en cuenta en un catálogo de objetos, de forma que pueda ser clasificado en un tema y grupo específicos.



- Tienen características que diferencian a las instancias de los objetos. - Tienen un tipo de información determinada (Carácter, Numérico, etc.) - Pueden tener valores predeterminados en cada atributo (dominio)

Operaciones: Son acciones de los objetos ejecutadas por sus instancias, se caracterizan por analizar posibles modificaciones de un objeto gracias a la alteración de uno de los valores de sus atributos. Una de sus principales características es que muestra la percepción que tienen las personas sobre los objetos geográficos, razón por la que son incluidas en los sistemas de información geográfica ya que modelan los fenómenos del mundo real.

Como el objetivo principal es la interoperabilidad de los datos resulta de gran importancia que su modelamiento permita dicho intercambio.

Relaciones: Las relaciones describen la interacción o vínculo entre diferentes objetos, la necesidad de intercambiar información entre los miembros de un tipo de objeto o entre diferentes tipos de objetos. Tienen grado y cardinalidad:

- Grado: 2, 3…….n - Cardinalidad: Relación Uno a Uno (1-1), Relación Uno a Muchos (1-M),

Relación Muchos a Uno (M-1), Relación Muchos a Muchos (M-M).

1.1.3 Modelo de datos:

Un modelo de datos geográfico es una “abstracción del mundo real que emplea un conjunto de datos y objetos que soportan ser desplegados como un mapa, consultas, edición y análisis5”. Es un conjunto de información que define las tablas, las relaciones existentes entre ellas, las operaciones y los atributos y dominios que permiten conocer exhaustivamente la estructura de la información.

El modelo de datos es una extensión, un nivel inferior del catálogo de objetos geográficos, ya que se encarga de modelar la estructura de la información geográfica para las temáticas particulares, retomando las necesidades y modelando las reglas de negocio para cada temática en particular. El modelo de datos debe ser diseñado por cada institución, debe partir de la base general que comprende el catálogo de objetos oficial.

5 Conceptos básicos y ArcSDE

Capítulo I 27

1.1.4 Portales y servicios geográficos en la web

En el marco de las IDE es relevante el desarrollo de las Páginas Web y Portales Web como medio que facilita las búsquedas y la difusión de datos geográficos requeridos a diferentes niveles, al interior y exterior de las organizaciones.

Los geoportales funcionan como conexión entre los datos geográficos y los usuarios de la información geográfica.

Figura 1-3: Difusión y Acceso a la IG - Geoportales Fuente: Arquitectura de Gestión de Conocimiento, Piattini, 2007

Los portales geográficos o geo-portales son los medios más usados en la actualidad para encontrar información geográfica en la web, ésta puede ser distribuida o tener el acceso en línea a la información de interés:

Las funciones y características de los portales geográficos son: representación del mapa, proyección de datos, consultas, diccionarios, metadatos de capas y de servicios, análisis de IG, visualización 2D y 3D, extracción de datos, descargas de programas y de archivos. En cuanto a las capacidades se tiene la búsqueda, mapas, publicación y administración.

Sin embargo, a pesar de los avances en materia de Infraestructura de Datos Espaciales, aún existen algunas limitaciones en la gestión y uso de datos geográficos en la web, principalmente en materia de integración y visibilidad de datos. En el marco de las tecnologías de la información geográfica surge la Web Semántica cuya finalidad es difundir otro paradigma respecto a la publicación de datos en la web, por medio de la aplicación de esta tecnología se pretender dar solución a dicha problemática.

Los estándares tecnológicos se encuentran definidos por la Open Geospatial Consortium - OGC creado en el año 1994 y conformado por organizaciones públicas y privadas entre las cuales se encuentra el IGAC, definiendo estándares abiertos e interoperables dentro de los SIG y de la World Wide Web para el uso del público e intercambio de información geográfica en la web.



De acuerdo con lo establecido en la página de la OGC: http://www.opengeospatial.org/standards/: En el desarrollo de aplicaciones de servicios web usando estándares OGC permiten “publicar”, “encontrar” y “enlazar” como funciones clave para aplicaciones en un entorno de servicios web.

Publicar: Proveedores de recursos publicitan sus recursos Encontrar: Los usuarios finales y sus aplicaciones pueden descubrir recursos que

necesitan en tiempo de ejecución Enlazar: Los usuarios finales y sus aplicaciones pueden acceder y ejecutar los

recursos en tiempo de ejecución

Muchos de los estándares OGC desarrollados son estándares para entornos de servicios web y estos estándares son referidos como OGC Web Services (OWS). La siguiente figura proporciona un esquema general de arquitectura para los OWS. Este esquema identifica las clases genéricas de servicios que participan en diversas actividades de geoprocesamiento y localización.

Figura 1-4: Web Service de OGC – Normas de Geoprocesamiento Fuente: http://www.opengeospatial.org/standards/

Catalogue Service for the Web (CS-W)

Filter Encoding (FE)

Geography Markup Language (GML)

KML Encoding Standard (KML)

Sensor Model Language (SensorML)

Style Layer Descriptor (SLD)

http://www.opengeospatial.org/standards/orm

http://www.opengeospatial.org/standards/orm

http://live.osgeo.org/es/standards/csw_overview.html

http://live.osgeo.org/es/standards/fe_overview.html

http://live.osgeo.org/es/standards/gml_overview.html

http://live.osgeo.org/es/standards/kml_overview.html

http://live.osgeo.org/es/standards/sensorml_overview.html

http://live.osgeo.org/es/standards/sld_overview.html

Capítulo I 29

Sensor Observation Service (SOS)

Web Coverage Service (WCS)

Web Feature Service (WFS)

Web Map Service (WMS)

Web Processing Service (WPS)

Sensor Model Language (SensorML)

Sensor Planning Service (SPS)

Web Terrain Service (WTS)

Grid Coverage Service

Coordinate Transformation Service

Web Coverage Processing Service (WCPS)

Web Map Tile Service (WMTS)

Simple Features (SF)

Sensor Web Enablement (SWE)

XML for Image and Map Annotation (XIMA)

CityGML

GeosciML

GML in JPEG 2000

Observations and Measurements (O&M)

Symbology Encoding

Transducer Markup Language (TML)

1.2 Web Semántica

La web semántica es una extensión de la red de datos actual dando a la información un significado “bien definido”, para facilitar a las computadoras y personas trabajar conjuntamente. Se basa en la idea de tener datos definidos en la web y vinculados, de manera que puedan ser utilizados para el descubrimiento más eficaz, la automatización, integración y reutilización a través de aplicaciones (Hendler et al., 2002).

La web semántica propone añadir semántica a la información de tal manera que se pueda establecer una relación o vínculo entre ellos; para lo cual se debe clasificar, estructurar y definir los recursos con semántica explícita para ser procesada por máquinas. La concepción de la web semántica es pasar de la navegación a través de documentos independientes a la navegación a través de datos vinculados, ya que éstos cobran un mayor valor cuando se encuentran interrelacionados.

http://live.osgeo.org/es/standards/sos_overview.html

http://live.osgeo.org/es/standards/wcs_overview.html

http://live.osgeo.org/es/standards/wfs_overview.html

http://live.osgeo.org/es/standards/wms_overview.html

http://live.osgeo.org/es/standards/wps_overview.html



En la web semántica cada objeto (página, documento, archivo, imagen, video, dato, etc.) se encuentra vinculado con otros recursos a través relaciones que a su vez también están diferenciadas por una tipología. Para añadir semántica a la información geográfica, es necesario tener en cuenta sus particularidades como las relaciones espaciales, tipos de geometrías, sistemas de referencia, simbología, entre otros.

1.2.1 Evolución de la web

Figura 1-5: Evolución de la web Fuente: Propia

El desarrollo de la web, a lo largo de la historia ha sufrido cambios significativos orientados a brindar tanto a los usuarios como a los productores de la red de datos, las herramientas necesarias para la difusión e intercambio de la información.

Con el nacimiento de la web, la web 1.0 consistía en una red de datos en la cual el productor emitía o difundía datos que finalmente eran consultados por los usuarios; sin embargo los productores accedían a datos tan solo de lectura, consistía en consultas de información unidireccional. Con la llegada de la web 2.0 los usuarios tienen la oportunidad de aportar información, correspondía a personas conectándose, colaborando, interactuando y compartiendo con otras; es allí cuando se observa el uso de redes sociales, blogs, wikis, cloud computing, etc. Finalmente y lo que propone Tim Berners-Lee, el padre de las web actual, para la web 3.0 (web semántica) es integrar las máquinas en procesos de análisis para mejorar la experiencia del usuario en la interacción con la información geográfica. Para Berners-Lee la Web semántica es una red de datos que puede ser procesada directa o indirectamente por máquinas, es una web extendida que permitirá a humanos y máquinas trabajar en cooperación mutua (Tim Berners-Lee, Weaving a Semantic Web, 2005).

http://es.wikipedia.org/wiki/Tim_Berners-Lee



Capítulo I 31

1.2.2 Componentes Web Semántica:

La web semántica plantea una definición adecuada de los datos que posteriormente nos permitirá establecer una relación en ellos y generar vínculos para su asociación, de tal manera que estos elementos ayudaran a convertir la web en una infraestructura global en la que es posible compartir, reutilizar datos y documentos entre diferentes usuarios. Los componentes para la definición de los datos son6:

RDF (Resource Description Framework): Es un modelo de datos para los recursos y las relaciones que se pueden establecer entre ellos. Aporta una semántica básica para ese modelo de datos que se puede representar en XML. Equivale a los registros de una base de datos.

SPARQL (Protocol and RDF Query Language): Corresponde al lenguaje de consulta sobre para RDF que permite hacer búsquedas sobre los recursos de las bases de datos semánticas utilizando distintas fuentes. DBPedia por ejemplo es un proyecto para la extracción de datos de wikipedia para proponer una versión de web semántica, este proyecto es realizado por la Universidad de Leipzig, Universidad Libre de Berlín y la compañía Open Link Software.

OWL (Web Ontology Lenguage): Corresponde al esquema de la base de datos. Es un mecanismo para desarrollar temas o vocabularios específicos en los cuales se asocian los recursos. OWL proporciona un lenguaje para definir ontologías que pueden ser utilizadas a través de diferentes sistemas, las ontologías incluyen definiciones de conceptos básicos en un campo determinado y la relación entre ellos.

1.2.3 Open Linked Data

“La web de los datos se concibe como un espacio global de datos basado en estándares abiertos. Para esto no solo basta con la tecnología necesaria para tener datos con la estructura adecuada para poder consultar e inferir conocimiento. Es además indispensable, que estos datos estén vinculados de manera que sirvan para la integración a gran escala, y el razonamiento automático. Sin datos vinculados es imposible pensar en una web de datos en las que una persona o máquina pueda explorarlos7”.

La web de datos enlazados o “web linked data” otorga a los datos dispuestos en la web “vínculos” permitiendo al usuario navegar a través de los datos y no sólo a través de los archivos, potencializando su uso y aprovechamiento.

La generación de Linked Data en el ámbito de la información geográfica catastral, puede aportar en la solución de la problemática de publicación y vinculación de datos geográficos catastrales con información proveniente de otras fuentes proporcionando a los usuarios

6 Surgimiento de la web que conocemos hoy en día 7 W3C. What is Linked Data?. { http://www.w3.org/standards/semanticweb/data

http://dbpedia.org/About



información con mayor contenido y posibilidad de análisis y relación espacial con otras fuentes de datos.

Principios Linked Data:

Los cuatro principios de diseño en los que se basa Linked Data son (Berners-Lee, 2006):

1. Utilizar URI (Uniform Resourse Indentifier) como nombres únicos para los recursos. 2. Utilizar el protocolo HTTP para nombrar y resolver la ubicación de los datos

identificados mediante esas URI. 3. Representar los datos en RDF y utilizar SPARQL como lenguaje de consulta de

dichos datos. 4. Incluir enlaces a otras URI para permitir la localización de más datos enlazados.

Formato:

El formato de datos del Linked Data es el RDF. Es un modelo construido con grafos, que está formado por un sujeto y objetos relacionados a través de un predicado (tripleta). Cada elemento puede ser representado con una URI. Y el objeto puede comportarse también como sujeto en otra tripleta. Para que los datos RDF puedan ser procesados de manera automática es necesario realizar una clasificación de los recursos y sus relaciones en un esquema conceptual consensuado ontología (Saavedra, 2011).

Figura 1-6: Tripleta funcionamiento RDF

Diferencia Web Actual – Web of Linked Data:

En la actualidad la navegación de información en la web se realiza a través de documentos html; sin embargo en la web de datos enlazados es posible realizar la navegación a través de recursos en formato RDF, el cual permite mantener una estructura y un vínculo. Al tratarse de datos con semántica, los motores de búsqueda pueden proporcionar mejores capacidades de consulta, lo que abre la posibilidad de aplicaciones basadas en el procesamiento automático e inteligente de los datos directamente desde en la Web.

Sujeto Objeto Predicado

Introducción 33

Figura 1-7: La web actual vs la web semántica Fuente: How to Publish Linked Data on the Web, Health T, Bizer C.

Según Tom Health y Christian Bizer con el Linked Data la web semántica se busca compartir datos estructurados en la red tan fácilmente como hoy se pueden compartir documentos. El supuesto básico detrás de datos vinculados “es que el valor y la utilidad de los datos aumentan en cuanto está más interrelacionada con otros datos. A diferencia de la web de hipertexto, donde se vinculan documentos de hipertexto escritos en HTML, en el Linked data se vinculan todo tipo de recursos descritos en RDF (referenciados con una URI Única) y se conoce la semántica del vínculo (forma parte de, es igual, vive en etc.). Esto permite que un usuario comience con un origen de datos y luego pueda moverse desde un sitio Web a una gran cantidad de fuentes de datos vinculadas por enlaces RDF. Además al tener datos con semántica los motores de búsqueda pueden proporcionar sofisticadas capacidades de consulta. Los resultados de estas consultas son datos estructurados y no sólo enlaces a páginas HTML. Esto abre múltiples posibilidades en una nueva generación de aplicaciones basadas en el procesamiento automático e inteligente de los datos directamente desde la web (Health Tom, Bizer Chirstian, How to Publish Linked Data on the Web)”.

1.2.4 Integración e interoperabilidad de datos heterogéneos

La Interoperabilidad habla de “La capacidad de comunicarse, para ejecutar programas o para transferir datos entre varias unidades funcionales de una manera que requiera al usuario tener poco o nada de conocimiento de las características únicas de esas unidades (ISO 2382.1, 1993; ISO 19119, 2002)”. Para alcanzar la denominada interoperabilidad el



modelo de información de ambos sistemas debe ser interoperable de forma sintáctica, estructural y semánticamente8.

Interoperabilidad Sintáctica:

Los estándares en general buscan lograr esta interoperabilidad mediante la estructuración de la información de modo que pueda ser procesada e interpretada a ambos extremos de los sistemas. En bases de datos un ejemplo de las diferencias es el modelo relacional y el orientado a objetos y su procesamiento de las transacciones por parte de los sistemas gestores de bases de datos. Otro ejemplo en el contexto de la IG es la dificultad para integrar información que viene de CAD y SIG y el uso de estándares propietario. La aparición de las IDE y el acercamiento a la arquitectura orientada a servicios, han hecho que hoy la mayoría de SIG tenga implícito el manejo de formatos de intercambio y el consumo y publicación de servicios estándar.

Interoperabilidad estructural:

Está relacionada con las diferencias entre los esquemas de las diferentes fuentes (heterogeneidad estructural). Para lograr esta interoperabilidad debe haber alguna forma de transformar de un esquema a otro (ISO 19119, 2002).

Una herramienta utilizada para este tipo de interoperabilidad son los mediadores y wrappers que funcionan de una manera similar a las bases de datos distribuidas pero permiten la integración de datos desde distintas fuentes (no solo bases de datos). En el contexto de las IDE se puede decir que las interfaces y servicios de procesamiento funcionan como wrappers y mediadores.

Interoperabilidad Semántica:

Esta encargada de asegurar que el contenido de la información intercambiada (significado) sea entendido de la misma manera por cualquier sistema. Por lo tanto dos sistemas son semánticamente interoperables si estos tienen un entendimiento común de la semántica de la información, permiten combinar información con otros recursos, transmitirlos y procesarlos. Es decir que los agentes que intervengan entiendan el contenido de lo que intercambian. El resultado de esta interoperabilidad es que dos sistemas pueden trabajar juntos sin necesidad o minimizando la intervención humana.

Podemos dividir la heterogeneidad semántica en dos clases:

Heterogeneidad cognitiva: cuando no existe una base común en las definiciones para los fenómenos comunes en diferentes catálogos o bases de datos.

8 Metodología de integración basada en ontologías de información de bases de datos heterogéneas en el dominio hidrográfico, Vilches et al., 2006, Sheth, 1998; Jang et al., 2007

Capítulo I 35

Heterogeneidad designativa: Hace referencia a fenómenos iguales

semánticamente pero que son nombrados de una manera distinta. Aparecen a menudo en forma de homónimos, sinónimos o incluso polisemia.

En información espacial existen algunos aspectos particulares que deben ser considerados en este tipo de integración. Para llegar a esta interoperabilidad es necesario utilizar una conceptualización común y compartida descrita de manera explícita (ontología).

Grado de generalización (asociado a escala y propósito) Representación geométrica Sistema de coordenadas Representación gráfica (simbología) Topología Definición del objeto (concepto) Idioma Calidad

1.2.5 Ontologías

La palabra “Ontología” viene del griego “ontos” y “logos”, el primer término hace referencia al “ser”, “ente”, por su parte “logos” significa “estudio”, “teoría”, “ciencia”. De esta forma esta la ontología hace parte de una rama de la filosofía que estudia la naturaleza del ser, la existencia y la realidad; determina las categorías y las relaciones del ser.

La web semántica rescata la noción de ontología del campo de la filosofía, y la trae al contexto de la ingeniería del conocimiento para hacer una explicación sistemática de los recursos que componen la web. Así, los recursos que componen la web deben tener una explicación conceptualizada, formal, explicita y compartida (Gruber, 1993):

La ontología debe ser “conceptualizada”: Modelo abstracto de la realidad La ontología debe ser “explicita”: Los conceptos definidos explícitamente La ontología debe ser “formal”: Lenguaje entendible por las maquinas La ontología debe ser “compartida”: Conocimiento consensuado por un grupo o

comunidad de expertos y no uno individual

De esta forma, el modelamiento de ontologías para recursos disponibles en la web debe corresponder:

Definición de las clases para cada recurso ontológico dispuesto en la web Establecer la relaciones entre las clases y las demás ontologías Definición de las funciones para cada recurso, de forma individual y colectiva. Determinación de los axiomas de cada recurso ontológico definido Determinación de las instancias



Relaciones de las Ontologías:

Según estas relaciones existentes las ontologías se pueden clasificar en (Suárez-Figueroa et al., 2008):

Ontologías individuales: Una ontología que no tiene ningún tipo de relación con otras.

Ontologías individuales interconectadas: Se caracterizan por poseer entre ellas algún tipo de relación.

Redes de ontologías: Son una colección de ontologías relacionadas entre sí mediante diferentes relaciones.

Especificaciones de Ontologías (W3C):

Existen dos especificaciones de la World Wide Web Consortium - W3C concernientes a la formalización de ontologías:

RDF-Schema (RDF-S) - (Resource Description Framework - Schema): Lenguaje que proporciona los elementos básicos para la descripción de vocabularios RDF9.

Web Ontology Lenguage (OWL): Lenguaje de marcado para publicar y compartir datos usando ontologías. Tiene como objetivo facilitar un modelo de marcado construido sobre RDF10.

Recursos ontológicos (OR):

Son recursos de conocimiento cuya semántica ha sido formalizada en una ontología. Modelan el conocimiento sobre algunos dominios particulares y representan algún grado de consenso.

Recursos no Ontológicos (NOR):

Son recursos de conocimiento cuya semántica no ha sido todavía formalizada en una ontología. Hay una gran cantidad de NORs que incorporan conocimientos sobre algunos dominios particulares y que representan algún grado de consenso11.

1.3 El catastro predial

La resolución 70 de 2011 define en el artículo primero, el catastro como el “Inventario o censo, debidamente actualizado y clasificado, de los bienes inmuebles pertenecientes al

9 http://www.w3.org/TR/rdf-schema/ 10 http://www.w3.org/TR/owl-features/ 11http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/technologies/57-nor2o

http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/technologies/57-nor2o

Capítulo I 37

Estado y a los particulares, con el objeto de lograr su correcta identificación de los elementos físico, jurídico, económico y fiscal”.

El componente físico del catastro obedece a la conformación de una base de datos de información geográfica catastral a partir de la cual es posible describir todas las características físicas de los bienes inmuebles pertenecientes al estado o a un particular.

1.3.1 Objetivos Generales del Catastro:

Los objetivos generales del catastro se encuentran establecidos en la resolución 70 de 2011:

1. Elaborar y administrar el inventario nacional de bienes inmuebles mediante los procesos de Formación, Actualización de la Formación y Conservación Catastral.

2. Producir, analizar y divulgar información catastral mediante el establecimiento de un Sistema de Información del Territorio, que apoye la administración y el mercado eficiente de la tierra, coadyude a la protección jurídica de la propiedad, facilite la planificación territorial de las entidades territoriales y contribuya al desarrollo sostenible del país.

3. Conformar y mantener actualizado un sistema único nacional de información que integre las bases de datos de las diferentes autoridades catastrales.

4. Facilitar la interrelación de las bases de datos de Catastro y de Registro con el fin de lograr la correcta identificación física, jurídica y económica de los predios.

5. Entregar a las entidades competentes la información básica para la liquidación y recaudo del impuesto predial unificado y demás gravámenes que tengan como base el avalúo catastral, de conformidad con las disposiciones legales vigentes.

6. Elaborar y mantener debidamente actualizado el Sistema de Información Catastral.

El objetivo número 3, establece que se debe conformar un único sistema catastral que integre las bases de datos de las diferentes autoridades catastrales independientemente de sus procedimientos y metodologías internas de trabajo. En Colombia existen cuatro autoridades catastrales que operan de manera descentralizada generando cada una sus metodologías particulares de trabajo, así como sus modelos de datos para uso y manipulación de la información espacial; este escenario ha desencadenado una problemática en el momento de integrar y unificar sus bases de datos a fin de establecer un único sistema catastral, que permita además de la consolidación y consulta integrada de la información resultante de los procesos catastrales, la difusión e intercambio de los datos para múltiples usos. Un primer avance en este aspecto se ve reflejado en la unificación del código predial catastral nacional cuyo resultado fue producto de una serie de reuniones entre las diferentes autoridades catastrales realizadas entre el año 2011 y 2014.



1.3.2 El catastro multifinalitario

Figura 1-8: La Visión de la Evolución del Catastro Fuente: Catastro Multifinalitario aplicado a la definición de políticas de suelo urbano, Lincoln Institute Of Land Policy, 2007

La concepción planteada por la Federación Internacional de Agrimensores – FIG de un catastro multifinalitario se concibe desde la percepción de mantener un sistema de información catastral multifuncional. Las entidades que tienen a cargo las actividades catastrales podrían pensar que simplemente con proveer a las demás instituciones información con calidad y confiabilidad de la descripción física, jurídica, económica y fiscal del predio, están contribuyendo a la multifuncionalidad; sin embargo es una concepción errada respecto a esta temática, ya que en realidad implementar un catastro multifuncional implicaría integrar a todas las instituciones no sólo del ámbito catastral sino también del ámbito social, ambiental, cultural, entre otras, que trabajan con datos con el detalle predial para conformar una base de datos integral que supla las necesidades requeridas por cada institución; realmente la tarea correspondería añadir a las bases de datos catastrales además del aspecto físico, jurídico, económico y fiscal, los datos sociales, ambientales, culturales, etc., de la propiedad inmobiliaria. En realidad, “no es la institución catastral quien debe disponer la totalidad de sus datos en un sistema, sino que su base parcelaria debe ser tomada como referencia para relacionar todos los datos administrados por las diferentes instituciones que generen y requieren información territorial, interconectando todas ellas a través de la base cartográfica parcelaria única oficial del catastro de cada parcela”12. A nivel Distrital a través de IDECA han centrado sus esfuerzos para lograr la consolidación entre las bases de datos espaciales e integradas entre la entidad catastral y

12 Erba, D. A. Catastro Multifinalitario aplicado a la definición de políticas de suelo urbano, Cambridge, MA: Lincoln Institute Of Land Policy, 2007

Capítulo I 39

las demás entidades administrativas; sin embargo a nivel nacional, este aspecto ha tenido mayor complejidad por la heterogeneidad de los datos y las metodologías de trabajo.

La visión concebida por la FIG acerca de la evolución del catastro en América Latina a lo largo del tiempo es enmarcada en 5 olas o etapas por las cuales ha pasado el catastro territorial. A partir de la cuarta ola se proyecta que a partir del 2014 se haya superado las restricciones en la recuperación de inversiones por medio de la vía tributaria que corresponde al fin primario del catastro, la quinta ola indica la inversión e implementación de tecnologías de punta que permitan hablar propiamente de la existencia de catastros multifuncionales que aporten potencialmente por medio de sus bases de datos catastrales integrales en las actividades de planeación y desarrollo territorial del país.

El artículo 155 de la resolución 70 de 2011, indica que el IGAC y las demás autoridades catastrales deben garantizar la preservación, recuperación y acceso a la información catastral vigente e histórica, sin importar el medio o soporte en que se encuentre. Igualmente, deben implementar nuevas tecnologías para el mejoramiento de los procesos catastrales para migrar, producir y conservar la información catastral en medio digital, dentro del marco de la política de gobierno en línea.

Las Tecnologías de Información Geográfica - TIG se han convertido en una herramienta fundamental en los proyectos catastrales adelantados a nivel nacional. Proporcionan herramientas que comprenden la captura, manipulación y análisis de datos relacionados con el espacio geográfico en el que habitamos. Además, su capacidad para visualizar la información espacial es un elemento importante para la comunicación, difusión e intercambio de datos.

1.3.3 Estructura del Catastro Nacional

En Colombia, el Instituto Geográfico Agustín Codazzi – IGAC, es la entidad oficial que se encarga de elaborar el catastro nacional de la propiedad inmueble. En el año 2011 el IGAC estableció la resolución 70, por la cual se reglamenta técnicamente los procesos de formación, actualización de la formación y conservación del catastro nacional.

La subdirección de catastro del IGAC es la encargada de proponer y ejecutar los diferentes planes, políticas, reglamentos, proyectos, etc., para la producción, actualización, mantenimiento y difusión de la información y datos catastrales. De igual manera es la encargada de mantener actualizada la base nacional de datos catastrales a nivel de predio con sus atributos físicos, jurídicos, económicos y fiscales; de esta manera debe mantener actualizado el SIT (Sistema de Información de Tierras), y proporcionar información real y confiable para fines tributarios. La subdirección de catastro cuenta con 22 direcciones territoriales, que lo representan en las áreas de catastro, agrología, geografía y cartografía, siendo responsables de sus actuaciones y ejecutoras del Plan de Desarrollo Institucional, cuyas oficinas se encuentran localizadas en las cabeceras municipales distribuidas alrededor del país, adicionalmente cuenta con 43 Unidades Operativas de Catastro ubicadas en algunos municipios de mayor dinámica catastral.

Además de contar con el IGAC como máxima autoridad catastral en el país, el catastro nacional cuenta con el apoyo de cuatro autoridades catastrales descentralizadas que trabajan bajo los lineamientos legales y normativos establecidos por el IGAC pero que a



su vez tienen total autonomía en cuanto a las metodologías internas de trabajo así como la autonomía económica y financiera para ejecutar los procesos catastrales; tales son:

La unidad administrativa especial de catastro distrital de Bogotá La subsecretaría de despacho de catastro de Medellín La dirección de sistemas de información y catastro de la gobernación de Antioquia La subdirección de catastro municipal de Cali

Figura 1-9: Esquema Organizacional del Sistema Catastral Nacional Fuente: Subdirección de Catastro – Instituto Geográfico Agustín Codazzi

1.3.4 Modelos de Datos Catastrales Nacionales

Modelo Catastral Nacional

El artículo 34 de la resolución 70 de 2011 define la base de datos catastral como el compendio de la información alfanumérica y gráfica referente a los aspectos físicos, jurídicos y económicos de los predios inscritos en el catastro. El modelo de datos catastral permite asociar, simplificar la complejidad de la realidad reduciéndola a entidades representativas y relaciones entre las mismas. El modelo de datos fija qué información va a ser tratada por el sistema, quedando fuera del mismo todo lo no reflejado en dicho modelo y permite hablar de una única descripción física del predio más allá de su representación gráfica y alfanumérica.

El modelo de datos catastral nacional emitido por la Subdirección de Catastro del IGAC fue diseñado bajo los parámetros establecidos por el catálogo de objetos oficial y como resultado de consolidar las necesidades evidenciadas en las Direcciones Territoriales para el inventario, almacenamiento, manipulación y administración de la información geográfica

Capítulo I 41

resultado de los procesos de formación, actualización de la formación y conservación catastral. El detalle de este modelo de datos se abordará en el capítulo tres del presente proyecto.

Modelo Catastral Distrital

El catastro de la ciudad de Bogotá es un catastro descentralizado, La Unidad Administrativa Especial de Catastro Distrital – UAECD, es la entidad oficial encargada de las actividades relacionadas con la formación, conservación y actualización del inventario de los bienes inmuebles del Distrito Capital a partir del estudio de sus elementos físico, jurídico, económico y fiscal.

La UAECD se encarga de censar la información de cada predio y la inscriben en sus bases de datos de forma textual y gráfica, de esta manera se dispone de una base única y oficial de información georreferenciada que de forma dinámica registra los cambios que experimenta cada unidad predial, desde la cual también asigna y fija oficialmente los indicadores prediales como los son el chip, código de sector, cédula catastral, e igualmente la Nomenclatura Vial y domiciliaria. Esta información es un aporte fundamental para las diferentes instituciones públicas y privadas para la toma de decisiones relacionadas con planeación y la administración de la ciudad.

En la actualidad la UAECD cuenta con un componente en su estructura organizacional, el grupo de Infraestructura de Datos Espaciales del Distrito Capital (IDECA) cuya misión corresponde “Disponer la información geográfica del Distrito a partir del desarrollo y la articulación de las capacidades técnicas, tecnológicas, organizacionales y funcionales en cada una de las entidades vinculadas, buscando que la producción, administración y distribución de la información geográfica se realice en un ambiente comunitario bajo parámetros de calidad, eficiencia, oficialidad y oportunidad en beneficio de la ciudad y del país”13. El detalle de este modelo de datos se abordará en el capítulo tres del presente proyecto.

1.3.5 Número Predial Nacional

Aunque el modelo de datos es el resultado de las necesidades evidenciadas en las Direcciones Territoriales en la labor de almacenar el aspecto físico, jurídico y fiscal resultado de los procesos catastrales, se ha generado una problemática a la hora de homologar el modelo de datos implementado en las Direcciones Territoriales con los modelos de datos de los catastros descentralizados. A la fecha se han desarrollado reuniones técnicas de consolidación entre el IGAC y los catastros descentralizados: la unidad administrativa especial de catastro distrital de Bogotá, la subsecretaría de despacho de catastro de Medellín, la dirección de sistemas de información y catastro de la

13 http://www.ideca.gov.co/index.php?q=es/content/misi%C3%B3n-y-objetivos-estrat%C3%A9gicos

http://www.ideca.gov.co/index.php?q=es/content/misi%C3%B3n-y-objetivos-estrat%C3%A9gicos



gobernación de Antioquia y la subdirección de catastro municipal de Cali; con el fin de unificar el criterio respecto al uso e implementación del código predial catastral a nivel nacional. El resultado inicial de dicha consolidación fue la definición oficial de las 30 posiciones que corresponde al código predial catastral a nivel nacional, esta situación condujo a la modificación de los modelos de datos catastrales manejados por las entidades a nivel nacional.

Figura 1-10: Componentes del Número Predial Nacional Fuente: Subdirección de Catastro – Instituto Geográfico Agustín Codazzi

1.3.6 Caracterización de los Servicios Web para el Catastro

IGAC - GEOPORTAL

En la página del IGAC (www.igac.gov.co) es posible encontrar para consulta el Mapa del Sistema Nacional Catastral, allí es publicada la información gráfica y alfanumérica catastral de los predios a nivel nacional en custodia del IGAC.

Este servicio se encuentra dispuesto como un servicio WMS (Web Map Service) para el público en general; sin embargo, para las instituciones públicas con las cuales el IGAC tiene convenio, es posible disponer el servicio a partir de un WFS (Web Feature Service)

Capítulo I 43

El Geoportal posee una aplicación que permite la consulta y la visualización de la información tanto gráfica como alfanumérica catastral dispuesta en el siguiente enlace: http://geoportal.igac.gov.co/ssigl2.0/visor/galeria.req?mapaId=23.

Figura 1-11: Aplicación de consulta web de datos Catastrales - IGAC Fuente: Instituto Geográfico Agustín Codazzi, http://geoportal.igac.gov.co

UAECD - Geoportal de Bogotá

La Unidad Administrativa Especial de Catastro Distrital, a través de IDECA tiene los siguientes medios para la difusión de sus datos del mapa de referencia en la Web:

http://geoportal.igac.gov.co/ssigl2.0/visor/galeria.req?mapaId=23

http://geoportal.igac.gov.co/



Figura 1-12: Portal de Mapas de Bogotá Fuente: Unidad Administrativa Especial de Catastro Distrital, http://mapas.bogota.gov.co/geoportal/

UECD - Catálogo de Datos Geográficos Mapa de Referencia

Datos disponibles para descarga directa en formatos DWG, SHP, GML y KMS. Contempla todos los datos del mapa de referencia y datos temáticos provenientes de diversas entidades del Distrito. Adicionalmente es posible acceder a los servicios WMS del Mapa de referencia14 de Bogotá

14http://mapas.catastrobogota.gov.co/arcgiswsh/Mapa_Referencia/Mapa_referencia/MapServer/WMSServer?

http://unidad/

http://mapas.bogota.gov.co/geoportal/

Capítulo II 45

2. CAPÍTULO II: PLANTEAMIENTO

Este capítulo comprende el planteamiento general del presente proyecto de investigación. Para tal fin, se encuentra dividido en 3 secciones de interés: inicialmente se establecen los objetivos generales y específicos, delimitación del alcance y para finalizar la metodología establecida para el desarrollo del proyecto.

2.1 Objetivos

2.1.1 Objetivo General:

Realizar la integración de modelos de datos geográficos catastrales a partir de la construcción de redes de ontologías, para su publicación y vinculación con otros datos relacionados en la web bajo los lineamientos de Open Linked Data y web semántica; esto con el fin de potencializar el uso y difusión de datos en el marco del catastro multifinalitario.

2.1.2 Objetivos Específicos:

1. Realizar el diagnóstico del estado actual del tema a nivel internacional mediante

el análisis de modelos internacionales, recopilación de información de vocabularios, tecnología disponible e inventario de posibles conjuntos de datos a vincular de proyectos similares; con el fin encontrar fuentes de información idónea en materia de integración catastral y vinculación de datos bajo el contexto de la web semántica.

2. Analizar el modelamiento de la información geográfica catastral en custodia del IGAC y el catastro descentralizado de Bogotá, a partir de la comparación y caracterización de sus modelos de datos geográficos catastrales, con el fin de evidenciar sus particularidades y capacidades de integración entre sí y con respecto a estándares internacionales.

3. Desarrollar redes de ontologías que permitan la integración de los modelos de

datos geográficos catastrales del IGAC y catastro descentralizado de Bogotá.



4. Realizar la publicación y vinculación de un subconjunto de datos geográficos

catastrales con otros datos relacionados en la web bajo los parámetros de Open Linked Data.

2.2 Alcance

El presente proyecto de investigación abordará la integración del modelo de datos del catastro nacional (IGAC) y el modelo de datos de uno de los catastros descentralizados de Colombia (el de la ciudad de Bogotá) utilizando redes de ontologías. Además de la publicación y vinculación a otros datos relacionados bajo el contexto de la web semántica.

Se llevara a cabo adicionalmente un piloto a partir de la publicación y vinculación en la web de un subconjunto de datos catastrales correspondiente al municipio de Soacha y la ciudad de Bogotá.

2.3 Metodología

Para el planteamiento general de las fases del presente proyecto de investigación se tomó como base la metodología RUP “Rational Unified Process”15, la cual plantea el desarrollo de un sistema por fases iterativas (Iniciación, Elaboración, Construcción y Transición).

Figura 2-1: Fases y actividades en la metodología RUP Fuente: Metodología RUP “Rational Unified Process”

15 http://www-306.ibm.com/software/awdtools/rup/

http://www-306.ibm.com/software/awdtools/rup/

Capítulo II 47

De acuerdo a lo anterior, las fases en las cuales se enmarca el presente proyecto de investigación:

1. Fase de Iniciación: En el marco del planteamiento de este proyecto corresponde a la primera iteración, en la cual se busca explorar la tecnología y conocer la problemática.

2. Fase de Análisis y Diseño: Comprende todos los aspectos de análisis y diseño orientados a establecer las directrices a seguir para el desarrollo del proyecto.

3. Fase de Construcción: Comprende el desarrollo del proceso e implementación

de las actividades orientadas al cumplimiento de los objetivos planteados. Además comprende la evaluación iterativa hasta garantizar la calidad de los datos.

A su vez, cada una de las fases es dividida en las etapas generales del proceso, las cuales están comprendidas en cada uno de los capítulos que siguen a continuación:

Figura 2-2: Fases y etapas del proceso

Fuente: Propia



2.3.1 Fase de Iniciación:

Las actividades comprendidas en esta fase se llevaran a cabo a partir de las siguientes etapas de trabajo:

Capítulo 1: Marco Teórico y Conceptual: La finalidad de este capítulo es orientar al lector respecto de los aspectos conceptuales y teóricos acerca de los temas trabajados en el desarrollo del proyecto.

Capítulo 2: Etapa de Formulación (Planteamiento): Comprende las actividades correspondientes a la formulación del proyecto que permita establecer claramente la planeación y programación del mismo:

Tabla 2-1: Actividades Fase de Iniciación

Capítulo II 49

2.3.2 Fase de Análisis y Diseño:

Las actividades comprendidas en esta fase se llevaran a cabo a partir de las siguientes etapas de trabajo:

Capítulo 3: Etapa de Análisis de Fuentes y Diseño General del Sistema: La etapa de análisis y diseño se encuentra a su vez divida en dos subcapítulos: - Diagnóstico y análisis de fuentes: En el cual se realiza la investigación en el

contexto internacional respecto a los diferentes proyectos emprendidos aplicando esta tecnología en la temática de integración de datos geográficos catastrales, con el fin de desarrollar las ontologías a partir de la reutilización, reingeniería, mezcla, reestructuración y/o localización de los recursos ontológicos y no ontológicos de acuerdo a las fuentes analizadas.

- Diseño general del sistema: Comprende la investigación en el contexto internacional de las tecnologías de implementación disponibles para el desarrollo de las ontologías, publicación y vinculación de datos que involucren el componente geográfico.

Capítulo 4: Etapa de modelamiento de datos: Comprende la definición de las especificaciones técnicas de los datos catastrales de las entidades participantes y las respectivas ontologías a desarrollar en correspondencia con el análisis y caracterización de los modelos de datos catastrales para lograr la integración entre sí y en el contexto internacional.

Tabla 2-2: Actividades Fase de Análisis y Diseño



2.3.3 Fase de Construcción:

La fase de construcción comprende las actividades tendientes a desarrollar el tercer y cuarto objetivos específicos.

Capítulo 5: Desarrollo de Ontologías (Integración de modelos de datos catastrales): Esta etapa comprende el desarrollo de las ontologías y construcción de la red de ontologías:

Capítulo 6: Etapa de generación, publicación y vinculación de Datos: Comprende la conversión de los datos geográficos catastrales a formato RDF y su documentación de acuerdo a los estándares definidos. Además comprende la publicación y vinculación de los datos geográficos catastrales a otros datos relacionados en la web bajo los lineamientos de linked open data:

Tabla 2-3: Actividades Fase de Construcción

Adicionalmente en el marco de los procesos y las actividades específicas se tomó como base metodologías específicas, que se consideraron las mejores en su campo: Para las actividades asociadas a la generación de ontologías la metodología Neon16. Para la integración de información se utilizó como base la metodología planteada por (Vílchez, 2011) y para la publicación y vinculación de datos las actividades establecidas en (Saavedra, 2011).

16 http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/methdologies/59-neon-methodology

http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/methdologies/59-neon-methodology

Capítulo III 51

3. CAPÍTULO III: ANÁLISIS DE FUENTES Y DISEÑO GENERAL DEL SISTEMA

Este capítulo comprende el análisis de las fuentes con el diagnóstico sobre la temática abordada, a partir del mismo se establecen los recursos reutilizables en el marco del proyecto. En el segundo apartado del presente capítulo la atención se centra en el estudio y definición del diseño técnico y funcional del sistema. Esto, considerando los criterios de viabilidad técnica, operativa y económica. En este capítulo se establece la arquitectura para la generación de ontologías y datos, su publicación y vinculación.

3.1 Análisis de Fuentes

Con el fin de tener una visión del estado actual del tema, se realiza la revisión del estado del arte en materia de:

- Revisión y análisis de proyectos similares y modelos internacionales - Arquitectura, lenguajes y tecnologías de la web semántica - Recopilación de información de vocabularios - Inventario de posibles conjuntos de datos a vincular

3.1.1 Revisión de fuentes y modelos internacionales

Como resultado de la revisión del estado del arte, se encontraron investigaciones relacionadas que pueden aportar información al proyecto y que hacen referencia a:

Modelos estandarizados para integración de datos catastrales Integración Catastro – Registro Aplicación de web semántica en datos catastrales Aplicación de web semántica en integración de información y publicación de datos

como Linked Data

A continuación se referencian brevemente cada una de las investigaciones encontradas:



Modelos estandarizados para la integración de datos catastrales

Tabla 3-1: Representación Espacial de Condominio y Co-Propiedad

Titulo Representación espacial de condominio y co-propiedad: “Comparación sistema catastral de Quebec y el Francés basado en la especificación LADM”

Autores Pouliot, Jacynthe y Vasseur, Marc

Fecha Publicación: Noviembre 2011

RESUMEN

Con el fin de avanzar hacia un sistema de gestión catastral que integra 3D, se realiza la comparación de la representación 3D de la copropiedad vertical entre Quebec y jurisdicciones francesas. Además como parte del análisis se realiza comparación con base en el modelo de datos de la administración de tierra LADM. Como resultado del análisis se proponen esquematizaciones LADM en la representación espacial 3D de la copropiedad vertical adoptada por ambas jurisdicciones.

LÍNEA DE INVESTIGACIÓN


Tabla 3-2: Modelo LADM/STDM: Visión para el 2025

Titulo From LADM/STDM to a Spatially Enabled Society: “a Vision for 2025”

Autores Uitermark, Harry; Oosterom, Peter Van; Zevenbergen, Jaap y Lemmen, Christiaan

Fecha Publicación: 2010

RESUMEN

Este artículo explica que es LADM y STDM. El “Land Administration Domain Model (LADM)” es un modelo que busca ser el estándar en materia de Administración de la tierra y catastro, se encuentra en discusión su conversión a ser una norma internacional de ISO (ISO 19152) habla también sobre el “Social Tenure Domain Model (STDM)”, aplicación basada en LADM que busca su fácil aplicación en países en desarrollo.



Capítulo III 53

Tabla 3-3: Proyecto Norma ISO TC 211 19 152 sobre Modelo Catastral

Titulo Revista red de expertos iberoamericanos en Catastro. Artículo: “Proyecto de Norma ISO TC 211 19 152 sobre el Modelo Catastral”

Autores Martín-vares y Amalia Velasco


RESUMEN

Contiene información sobre que es la norma ISO TC 211 19152, su proceso de elaboración, los principales aspectos que define y los beneficios derivados de su implementación.



Tabla 3-4: Modelo de datos de parcelas “INSPIRE”

Titulo Presentación IDE España

Autores Dirección General de Catastro de España

RESUMEN

Muestra una introducción a Inspire y la Infraestructura de Datos Española. Detalla como maneja España el tema de catastro, habla de la especificación para parcelas catastrales, LADM y STDM. Además, explica que el modelo de datos de las parcelas catastrales de INSPIRE se ha preparado de manera que soporta compatibilidad con el LADM (Land Administration Domain Model). La conexión con el LADM ofrece un contexto más amplio para las parcelas catastrales que incluye información adicional de derechos, titulares, etc…que están fuera del objetivo de INSPIRE”.



Tabla 3-5: Core Cadastre Domain Model (CCDM)17

Titulo Core Cadastral Domain Model

Autores Oosterom, Peter Van y Lemmen, Christiaan

17 http://www.gdmc.nl/3dcadastres/literature/3Dcad_2006_09.pdf

http://www.gdmc.nl/3dcadastres/literature/3Dcad_2006_09.pdf




RESUMEN

Busca evitar la reinvención de la rueda cuando se habla de modelos para sistemas catastrales, basándose en la afirmación que aunque parezcan muy distintas en el fondo las cosas básicas son las mismas. Mediante la aplicación de ontologías y el modelo CCDM se quiere mejorar la comunicación entre proyectos o instituciones de diferentes países o ámbitos. Presenta el proceso de desarrollo de este modelo y ejemplos de su implementación en varios países como Holanda, El Salvador, Bolivia, Dinamarca, Suecia entre otros. Proviene de una iniciativa de la FIG con apoyo de múltiples organizaciones como OGC (Open Geospatial Consortium) y ONU para consolidar un modelo único de catastro. Está enfocado en la visión de catastro multipropósito. Busca tener un sistema catastral eficiente y efectivo basado en la Model Driven Architecture (MDA) y permitir la comunicación de sistemas con diferentes modelos. Fue tomado como base para la elaboración de LADM.


- Modelos estandarizados para la integración de datos catastrales - Ontologías

Integración Catastro – Registro

Tabla 3-6: Registro de la Propiedad Linked Open Data

Titulo Registro de la Propiedad Linked Open Data


RESUMEN

Se realiza la publicación de un conjunto de datos del registro de la propiedad pública aplicando los lineamientos de Linked Data para realizar búsquedas y consultas con la ayuda de SPARQL. Los conjuntos de datos publicados como datos vinculados son:

Índice de Precios: Conjunto de datos vinculados con enlaces a ONS y Ordnance Survey para describir

las regiones informó sobre dentro de los datos HPI.

Precio Pagado datos: Conjunto de datos vinculada contiene más de 400 millones triples.

Datos de transacciones: Conjunto de datos vinculada.

http://landregistry.data.gov.uk/


- Catastro – Registro

http://landregistry.data.gov.uk/data/hpi

http://www.ons.gov.uk/

http://data.ordnancesurvey.co.uk/

http://landregistry.data.gov.uk/data/ppi/transaction-record

http://landregistry.data.gov.uk/data/trans/applications

Capítulo III 55

Tabla 3-7: Metodología basada en LADM, STDM, INSPIRE

Titulo Development Methodology for an Integrated Legal Cadastre: “Deriving Portugal Country Profile from the Land Administration Domain Model”

Autores Joâo Paulo da Fonseca Hespanha de Oliveira


RESUMEN

Tesis que busca plantear una metodología para el catastro desde la perspectiva de las tecnologías modernas a partir de los estándares existentes (LADM, STDM, Inspire) que permita manejar de forma armonizada los aspectos, técnico, legal y organizacional del catastro. Muestra el caso de integración catastro registro de Portugal.


- Catastro – Registro - Modelos estandarizados para la integración de datos catastrales

Tabla 3-8: Aspecto Legal y Espacial LCDM

Titulo The development of cadastral domain model oriented at unified real estate registration of china based on ontology

Autores Li, Ming; Zhu, Xinyan; Shen, Chenhua; Chen, Di y Guo, Wei


RESUMEN

Desarrolló un modelo catastral para unificar los aspectos legal y espacial del catastro de China, esto para la unificación con el registro y reaprovechamiento de estos datos por parte de otras entidades. El modelo planteado se basa en el “Legal Cadastral Domain Model” (LCDM). Este modelo fue validado a través de un

prototipo.


- Catastro – Registro



Aplicación de Web Semántica en datos catastrales

Tabla 3-9: Ontología Catastro Venezuela

Titulo Ontología web semántica del registro catastral venezolano

Autores Dávila, Nelson


RESUMEN

Aplicación de web semántica en información catastral en Venezuela para coordinar tareas de registro y catastro en las diferentes entidades del gobierno venezolano y su interacción con el público. Para esto se desarrolló una ontología de dominio, unas reglas de lenguaje y un agente de consulta en lenguaje natural que responde preguntas como quien es el dueño de la casa V11 o donde está la casa V22.


- Web Semántica en datos catastrales

Aplicación de web semántica en Integración de información geográfica

Tabla 3-10: Metodología de integración basada en ontologías

Titulo Metodología para la integración basada en ontologías de información de bases de datos heterogéneas en el dominio hidrográfico

Autores Vilches, Luis


RESUMEN

Metodología para la integración de bases de datos geoespaciales heterogéneas, basada en ontologías. Caso de aplicación en el dominio hidrográfico.


- Web Semántica en integración de datos geográficos

Capítulo III 57

Tabla 3-11: Conflación semántica

Titulo Conflación semántica: “un estudio sobre la integración de información geoespacial basada en ontologías”

Autores Vilches, Luis y Gargantilla, Ramos


RESUMEN

Se proporciona una revisión de los diferentes enfoques existentes para llevar a cabo la conflación semántica entre diversos conjuntos de datos geoespaciales. La conflación semántica es la integración de información geoespacial de múltiples fuentes en un conjunto compuesto de features que poseen mayor precisión en posición y atributos que las fuentes originales.



Tabla 3-12: Red de ontología Santiago de Chile

Titulo Red de ontologías para el camino de Santiago

Autores Poveda, María


RESUMEN

Este documento detalla una metodología para la construcción de redes de ontologías y su aplicación en el caso del camino de Santiago.



Tabla 3-13: Metodología NeOn

Titulo NeOn Methodology for Building Ontology Networks: “Specification, Scheduling and Reuse”

Autores Suarez, María


RESUMEN



A partir de este documento se propone una metodología detallada para la construcción de redes de ontologías.



Aplicación de web semántica en integración de información y publicación de datos como Linked Data

Tabla 3-14: Cómo publicar Linked data en la web

Titulo How to Publish Linked Data on the Web

Autores Heath, Tom; Hausenblas, Michael; Bizer, Chris; Cyganiak, Richard y Hartig, Olaf


RESUMEN

Tutorial acerca de cómo publicar Linked data en la web


- Publicación de datos como Linked Data

Tabla 3-15: GeoSPARQL: Caso aplicación división territorial y administrativa de Colombia

Titulo Linked Data geográfico conforme a GeoSPARQL. Caso de aplicación: “División territorial y administrativa de Colombia”

Autores Saavedra, Jhonny


RESUMEN

Tesis de maestría acerca de cómo publicar datos geográficos conforme al estándar GeoSPARQL. Caso de aplicación en la división territorial de Colombia



Capítulo III 59

Tabla 3-16: Metodología para publicar Linked Data España

Titulo An Approach to Publish Spatial Data on the Web: “The GeoLinked Data Case”

Autores Vilches-Blázquez, Luis M; Villazón-terrazas, Boris; León, Alexander De; Priyatna, Freddy y Corcho, Oscar

RESUMEN

Propuesta metodológica para publicar Linked Data geoespacial basada en la experiencia de GeoLinked

data en España



Tabla 3-17: Evaluación de calidad de datos publicados

Titulo Quality Assessment Methodologies for Linked Open Data

Autores Zaveri, Amrapali; Rula, Anisa; Maurino, Andrea; Pietrobon, Ricardo; Lehmann, Jens y Auer, Sören


RESUMEN

Trata sobre formas de evaluar la calidad de los datos publicados como Linked Open Data.



Tabla 3-18: GeoSPARQL y Parliament

Titulo Enabling the Geospatial Semantic Web with Parliament and GeoSPARQL

Autores Battle, Robert y Kolas, Dave

Fecha Publicación: 2011 - 2012

RESUMEN

Introducción al Linked Data Geoespacial y su manejo en los principales Triple Stores. Explicación del estándar GeoSPARQL y su implementación en el Triple Store Parliament.





Tabla 3-19: Líneas de investigación de geo-semántica y proyección futura

Titulo Geospatial Semantics and Linked Spatiotemporal Data: “HTTPPast, Present and Future”

Autores Janowicz, Krzysztof; Scheider, Simón; Pehle, Todd y Hart, Glen


RESUMEN

Este artículo hace una descripción de las principales líneas de investigación que ha tenido la geo-semántica y explica hacia donde pueden dirigirse estas en el futuro.



Tabla 3-20: Web Semántica, ontologías y linked data: “Nuevas tendencias para la gestión de la información geográfica”

Titulo Web Semántica, ontologías y linked data: “Nuevas tendencias para la gestión de la información geográfica”

Autores Ibarra Rodríguez, Diego

Fecha Publicación: Junio 2015

RESUMEN

La Infraestructura de Datos Espaciales del Distrito Capital – IDECA brindó el primer seminario taller en Web Semántica, Ontologías y Linked Data como nuevas alternativas para la gestión de la información geográfica.


- Aplicación de web semántica en integración de información y publicación de datos como Linked Data

Capítulo III 61

3.1.2 Lenguajes y Tecnologías que sustentan la Web Semántica

A continuación se hace una breve descripción de los estándares y tecnologías usadas en el contexto de la Web Semántica:

Figura 3-1: Lenguajes y tecnologías básicas de la Web Semántica Fuente: Semantic Web Stack

A continuación se hace referencia a cada una de las tecnologías que hacen parte de la Web Semántica:

Tecnologías Web Base:

Hacen referencia a tecnologías que son la base de la “Web Tradicional” y que son reusadas en la “Web Semántica”:

Protocolo HTTP: Nace de la necesidad de tener una referencia única, no ambigua a los recursos que se disponen en la web. Para esto se utilizan los “Uniform Resource Identiers” (URIs).

Además es necesario tener en cuenta la existencia de los “ Internationalized resource identifier” (IRI) , que son una generalización de las URIs que permiten manejar caracteres del “Universal Character Set” (Unicode/ISO 10646) en el cual están incluidos caracteres de idiomas como el chino, japonés entre otros. Para des-referenciar la URI y obtener el contenido se utiliza el protocolo HTTP.18

XML: Nace de la necesidad de tener un leguaje para intercambiar la descripción de los recursos. EL “Extensible Markup Leguage” (XML) es usado para la creación de documentos compuestos de datos estructurados.

18 Andreas, Harth. et. Al, Semantic Web Architecture. 2010



Tecnologías Semánticas Estandarizadas:

Hace referencia a tecnologías estandarizadas por el W3C (World Wide Web Consortium):

“Resource Description Framework” (RDF): Permite la descripción conceptual de los recursos web. Esto, mediante la creación de sentencias en forma de tripletas que representan información acerca de los recursos en forma de grafos. Este formato ha sido desarrollado pensando en la posibilidad de integrar estos datos.19

“RDF Schema” (RDFS): Provee un vocabulario básico para RDF. Usando RDFS es posible por ejemplo crear jerarquías de clases y propiedades.

“Web Ontology Language” (OWL): Es un leguaje para la representación del conocimiento como ontologías. Tiene herramientas avanzadas para describir la semántica implícita en las tripletas RDF. Una ontología consiste en un conjunto de axiomas que aplican y restringen a un conjunto de individuos y los tipos de relaciones permitidas entre ellos. La semántica expresada a través de estos axiomas (descripción lógica) permite a los sistemas realizar inferencias que dan el poder de razonamiento a la Web Semántica.

SPARQL: Es el leguaje mediante el cual se consultan datos RDF. Permite manipular y consultar estos datos.

Tecnologías Semánticas:

RIF o SWRL: Las tecnologías semánticas en las cuales se está trabajando, RIF o SWRL Buscan brindar soporte a reglas que no pueden ser descritas mediante OWL.

Componentes de la arquitectura general de la web semántica “Semantic Web Stack”

En materia de software y componentes, la siguiente figura muestra la infraestructura más usada comúnmente en aplicaciones semánticas20.

19 http://en.wikipedia.org/wiki/Resource_Description_Framework 20 B. Heitmann, S. Kinsella, C. Hayes, and S. Decker. Implementing semantic web applications: reference architecture and

challenges. In Proceedings of 5th International Workshop on Semantic Web Enabled Software Engineering, co-located with

ISWC 2009, 2010

Capítulo III 63

Figura 3-2: Componentes de la arquitectura de la Web Semántica Fuente: Semantic Web Stack

Los componentes de software que pueden ser utilizados en el contexto de esta tecnología:

Servidor Web: Provee la infraestructura parta servir contenido vía HTTP.

Navegador Web: Permite la recuperación y presentación de los recursos.

RDF API/Parser: Permiten el procesamiento y gestión de los datos retornados en RDF. No existe una especificación estandarizada para procesar el contenido RDF. Sin embargo existen bastantes implementaciones Open Source de APIs para RDF (ARP jeena, Redland RDf Library etc...)

Repositorio RDF (RDF Stores): Son utilizados para almacenar, indexar, gestionar y consultar datos en formato RDF. Usualmente las consultas se hacen mediante el lenguaje SPARQL.

Razonadores (Reasoner): Se utilizan para explotar todas las posibilidades de inferencia que brinda el utilizar ontologías desarrolladas en OWL para modelar datos RDF.

Motor de reglas (Rule Engine): Sirven para procesar reglas establecidas en RIF.

Herramientas Criptográficas: Se utilizan para asegurarse de que las transmisiones de datos no puedan ser interceptados, leídos o alterados. También se encargan de la verificación de la autenticidad de los usuarios.

Capa de identificación e integración: Dado que los contenidos agregados de diferentes fuentes a menudo utilizan múltiples identificadores para denotar el



mismo objeto en el mundo real, es necesaria una capa que permita una mayor integración de los datos.

Procedencia y confianza: Esta capa se encarga de analizar los datos en conjunto con información adicional que proviene de los usuarios con una noción de la confianza que se puede tener de cada ítem.

Interfaz de Usuario: Permite a los usuarios interactuar con los datos. Estas pueden ser genéricas o especializadas en determinado dominio.

3.1.3 Recursos ontológicos y no ontológicos (modelos y vocabularios)

De acuerdo con el resultado de análisis de fuentes, se escogieron los siguientes recursos que responden a la temática de catastro y a la naturaleza geoespacial de la información catastral, se clasificaron como Recursos Ontológico y No Ontológicos, con el fin de identificar los recursos que podrían ser usados en la construcción de la red de ontologías:

Recursos No Ontológicos (RNO):

Modelo De Datos Catastral Nacional - IGAC (RNO)

En Colombia, el modelo de datos catastral se encuentra impartido a partir del Sistema Nacional Catastral (SNC). Para el desarrollo del Sistema Nacional Catastral se tomó como base el modelo de datos catastral oficialmente establecido por la Subdirección de Catastro, basado en el catálogo de objetos oficialmente establecido por el IGAC y el resultado del trabajo conjunto y consolidado entre las Direcciones Territoriales y los Catastros Descentralizados.

Este modelo de datos catastral será analizado en detalle en el siguiente capítulo del presente proyecto.

Modelo De Datos Catastral Para Bogotá - UAECD (RNO)

IDECA focalizo sus esfuerzos en generar un conjunto organizado de datos denominado “Mapa de Referencia”. Para documentar la estructura de los datos que contiene genero su catálogo de objetos21.

21 http://www.ideca.gov.co/sites/default/files/files/Proyectos/MR/EI%20-%20Cat%C3%A1logo%20de%20Objetos%20MR%20V4_2_2012.pdf

Capítulo III 65

El mapa de referencia publicado por la UAECD (Unidad Administrativa Especial de Catastro Distrital) contiene los datos básicos públicos del distrito y contemplan los datos catastrales y de división administrativa de la ciudad capital del país.

Este modelo será analizado en detalle en el siguiente capítulo del presente proyecto.

Recursos Ontológicos (RO) Datos Geoespaciales ISO: 19152 “Land Administration Domain Model” – LADM22 (RO)

Es una norma internacional que define un modelo para el ámbito de la administración del territorio. El propósito del LADM es proporcionar un lenguaje formal para describir los diferentes sistemas existentes, de manera que sus similitudes o diferencias se puedan entender mejor.

LADM establece un modelo estándar quiere lograr la armonización de una parte básica de todos los sistemas catastrales existentes, lo que llamamos el “core model”, que a la vez permita las distintas prácticas y procedimientos de los distintos catastros y además facilite el intercambio de la información entre los distintos sistemas catastrales.

LADM proporciona un modelo conceptual de referencia con el fin de cumplir con dos objetivos:

1. Proporcionar una base extensible para el desarrollo y refinamiento de sistemas eficientes y efectivos de administración del territorio, basados en una arquitectura guiada por el modelo MDA (Model Driven Arquitecture).

2. Permitir la comunicación entre los interesados involucrados, tanto dentro de un mismo país como entre diferentes países, basándose en un vocabulario común (ontología) que implica el modelo.

El núcleo del LADM se basa en 4 clases básicas:

1. Clase LA_Party. Las instancias de esta clase son interesados. 2. Clase LA_RRR. Las instancias de las subclases de LA_RRR son derechos,

restricciones o responsabilidades. 3. Clase LA_BAUnit. Las instancias de esta clase son unidades básicas

administrativas. 4. Clase LA_SpatialUnit. Las instancias de esta clase son unidades espaciales.

Estos cuatro paquetes son cada uno independientes entre sí y a través de un lenguaje UML se adaptan a las distintas situaciones, como veremos en el capítulo siguiente

22 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=51206

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=51206



Vocabulario “Basic Geo (WGS84 lat/long)”23 (RO)

Este es un vocabulario generado por el W3C (World Wide Web Consortium) como recomendación informal. Es un acercamiento inicial, con el fin de tener la posibilidad de representar la localización de los objetos en RDF. Este vocabulario usa como único sistema de referencia el WGS84 y solamente puede ubicar recursos como geometrías tipo punto a través de su latitud, longitud y altitud. Es por mucho el vocabulario más utilizado para referenciar espacialmente recursos dentro la web de Linked Data actualmente.

GeoSPARQL “A geographic query language for RDF data”24 (RO)

Esta norma del OGC define un vocabulario para la representación de los datos geoespaciales en RDF, y una extensión para el lenguaje de consulta SPARQL para el procesamiento de estos. Define:

Un vocabulario para representar objetos, geometrías, y sus relaciones

Las funciones espaciales para su uso en consultas SPARQL

Un conjunto de reglas de transformación de consulta que permite interactuar con los tipos de objetos y sus geometrías.

Esta norma cuenta con amplio respaldo institucional y está comenzando a ser implementada en varios Triple Stores y también en datos como los del Ordnance Survey y el USGS que están comenzando a migrar datos a esta estructura.

3.1.4 Datos potencialmente vinculables

El único conjunto de datos publicado como Linked Data dentro del ámbito geográfico Nacional: “entidades territoriales y administrativas de Colombia” (Saavedra, 2011). Sin embargo cabe la posibilidad de evaluar la información contenida en los siguientes proyectos que pueda ser integrable:

Dbpedia: Recoge el esfuerzo de una comunidad por extraer información

estructurada de Wikipedia, relacionando esta información con otros conjuntos de datos y haciéndola disponible en la web. Entre la información que recoge DBpedia25 aparece un importante volumen de información con carácter geográfico.

Geonames: Recoge información de datos geográficos, tales como nombres de

lugares, poblaciones, etc. de diversas fuentes. Asimismo, los usuarios pueden de forma manual editar, corregir y añadir nuevos topónimos26.

23 http://www.w3.org/2003/01/geo/ 24 http://www.opengeospatial.org/standards/geosparql 25 www.dbpedia.org 26 http://www.geonames.org/ontology/documentation.html

http://www.w3.org/2003/01/geo/

http://www.opengeospatial.org/standards/geosparql

Capítulo III 67

Linked GeoData: Es una iniciativa de la Universidad de Leipzig. Utiliza la información recopilada por el proyecto Open Street Map y la hace disponible en una base de conocimiento RDF de acuerdo con los principios de Linked Data. Tiene una ontología que clasifica temáticamente los objetos cartográficos según las etiquetas del Open Street Map. El manejo de la geometría lo hace a través de geoRSS (puntos, líneas y polígonos). Su modelo incluye listas con los puntos que componen las líneas y polígonos27.

GeoCOL28: Corresponde a un caso de aplicación de la publicación como Open

Linked Data conforme a SPARQL de los datos asociados a la división administrativa y territorial de Colombia.

3.2 Diseño General del Sistema

3.2.1 Tecnologías de implementación disponibles:

Para el desarrollo del presente proyecto, se requiere revisar las tecnologías de implementación existentes, ya que es posible que puedan utilizarse algunas de estas herramientas, así como posiblemente se necesiten desarrollos propios para cumplir las necesidades particulares del proyecto.

Generación de Ontologías

Entre las herramientas que se tienen disponibles para la generación y gestión de Ontologías se destacan:

Protégé29: Permite crear y editar ontologías. Es libre y de código abierto. Tiene dos plataformas una web y una desktop. Puede desarrollar ontologías en los formatos OWL, RDF(s) y XML(s). Es el software más usado y con una comunidad más activa. Es desarrollado por la Universidad de Standford.

27 http://linkedgeodata.org 28 SAAVEDRA VELÁZQUEZ, Jhonny Alexis. Linked Data Geográfico conforme a geosparql – caso de aplicación División Territorial y Administrativa de Colombia. Tesis de Maestría. Universidad Politécnica d Madrid. 2011 29 http://protege.stanford.edu/

http://protege.stanford.edu/



NeOn Tool Kit30: Es un ambiente que da herramientas que soportan todo el ciclo

de vida de la ingeniería ontológica, desarrollado como parte de proyecto Neon. Es de código abierto y multiplataforma.

gOntt31: Extensión de NeOn Tool Kit para dar soporte al desarrollo de ontologías con la metodología NeOn.

NOR2O32: Es una librería para transformar recursos no ontológicos en ontologías.

Gestión y publicación de Linked Data:

Las herramientas disponibles para el almacenamiento, gestión y publicación de linked data se tienen:

Virtuoso33: Plataforma para la gestión, acceso e integración de datos. Engloba en una sola herramienta el soporte de gestión de bases de datos relacionales, RDF, XML y texto libre. Sirviendo al mismo tiempo como servidor de documentos, Linked Data, aplicaciones y servicios. Está disponible tanto en software libre como una versión licenciada la cual tiene más funcionalidades como por ejemplo una interfaz de usuario más completa y sencilla de usar.

Oracle 12c - Spatial and Graph34: Funcionalidades opcionales para Oracle

Enterprise Edition que permiten la gestión y análisis de datos en RDF. Permite la visualización de datos de SGBD como RDF. Manejo de GeoSPARQL para almacenamiento y búsqueda de datos geoespaciales.

Parliament35: Triple Store y gestor de datos compatible con los estándares RDF, RDFS, OWL, SPARQL, y GeoSPARQL. Es desarrollado por Raytheon BBN Technologies y es de código abierto.

30 http://neon-toolkit.org/wiki/Main_Page.html 31 http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/technologies/61-gontt 32 http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/technologies/57-nor2o 33 http://virtuoso.openlinksw.com/ 34 http://www.oracle.com/us/products/database/options/spatial/overview/index.html 35 http://semwebcentral.org/frs/?group_id=159

http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/technologies/61-gontt

http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/technologies/57-nor2o

http://virtuoso.openlinksw.com/

Capítulo III 69

Figura 3-3: Arquitectura general de Parliament Fuente: Parliament User Guide, 2014

OWLIM36: Es un repositorio semántico de alto rendimiento. OWLIM es muy usado en repositorios de gran tamaño. Permite las consultas espaciales basadas en puntos y regiones. Es un software propietario con una versión ligera que puede ser usada de manera gratuita. Tiene una versión en la nube que se paga por horas de uso.

OpenSahara37: Desarrollado por Talking Trends es un framework de código abierto para la minería de texto con funcionalidades de procesamiento de lenguaje natural, indexado almacenamiento y búsqueda de datos RDF. Tiene soporte de GeoSPARQL y consultas temporales.

Strabon38: Triple Store con opciones de búsqueda espacio temporal con soporte del estándar GeoSPARQL. Muy enfocado en gestión de datos espaciales.

Generación de Linked Data

Algunos Triple Stores como “virtuoso” y “gestores de bases de datos” como Oracle permiten la generación automática de RDF. Sin embargo existen otras posibilidades adicionales al respecto:

36 http://www.ontotext.com/owlim 37 https://opensahara.com/en?destination=home 38 http://www.strabon.di.uoa.gr/

http://www.ontotext.com/owlim

https://opensahara.com/en?destination=home

http://www.strabon.di.uoa.gr/



D2RQ39: Permite el acceso a bases de datos relacionales como RDF de manera

virtual (usando SPARQL). Además, se pueden crear dumps RDF a partir de las bases de datos y es de código abierto.

Geometry2RDF40: Es una librería para generar ficheros RDF a partir de información geométrica (que puede estar disponible en GML o WKT). La versión actual de la librería trabaja con bases de datos geoespaciales.

R2O and ODEMapster41: Plugin del Neon Toolkit, que permite la exportación como RDF de datos almacenados en bases de datos relacionales.

RDF-RDB2RDF42: Herramienta para la exportación como RDF de datos almacenados en bases de datos relacionales.

Ultrawrap43: Tiene dos funcionalidades principales: Generación de RDF y OWL a partir de bases de datos relacionales y ejecución de consultas SPARQL sobre datos relacionales.

Vinculación de datos

Para vinculación de datos, las siguientes tecnologías de implementación disponibles:

Silk44: Herramienta para establecer relaciones entre instancias de datos que pertenecen a diferentes fuentes dispuesta como Linked Data. Mediante esta herramienta los publicadores de Linked Data pueden establecer los vínculos con otros conjuntos de datos. Existe una extensión st-silk45 que permite realizar comparaciones entre geometrías.

LIMES46: Herramienta para el descubrimiento de vínculos entre conjuntos de datos semánticos. Se dispone de una versión desktop y otra web.

3.3 Resumen de componentes de arquitectura utilizados:

Este proyecto se enfocará inicialmente en la integración, publicación y vinculación de datos.

39 http://d2rq.org/ 40 http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/technologies/151-geometry2rdf 41 http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/technologies/9-r2o-odempaster 42 https://metacpan.org/release/RDF-RDB2RDF 43 http://capsenta.com/ultrawrap 44 http://wifo5-03.informatik.uni-mannheim.de/bizer/silk/ 45 https://github.com/psmeros/stSilk 46 http://aksw.org/Projects/LIMES.html

http://d2rq.org/

http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/technologies/151-geometry2rdf

http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/technologies/9-r2o-odempaster

https://metacpan.org/release/RDF-RDB2RDF

http://capsenta.com/ultrawrap

http://wifo5-03.informatik.uni-mannheim.de/bizer/silk/

http://aksw.org/Projects/LIMES.html

Capítulo III 71

De acuerdo a las características del presente proyecto, en el cual se desarrollara un piloto de publicación y vinculación de datos geográficos catastrales de manera abierta, inicialmente se tendrán en cuenta los siguientes componentes de arquitectura de web semántica:

Servidor Web RDF API/Parser Repositorio RDF (RDF Stores)

3.3.1 Diagrama de arquitectura del sistema

Figura 3-4: Diagrama de arquitectura

Fuente: Propia

Los componentes de arquitectura utilizados están comprendidos en cinco etapas generales:

1. El análisis y modelamiento de los datos catastrales respecto a un estándar internacional.

2. La integración de los modelos de datos catastrales a partir del desarrollo y construcción de la red de ontologías

3. La generación del componente espacial y alfanumérico de los datos catastrales en formato RDF

4. Publicación de los datos a partir de la estabilización del repositorio RDF 5. La vinculación de los datos geográficos catastrales a otros datos publicados bajo el

contexto de Linked Open Data y que manejan el componente geográfico.



3.3.2 Componentes de arquitectura para el análisis y modelamiento de los datos catastrales:

Para el análisis de los modelos de datos geográficos catastrales inicialmente se realizará

un análisis de los modelos de datos respecto al estándar internacional de administración

de la tierra LADM a través de la herramienta Microsoft Excel.

Posteriormente se llevará a cabo el modelado a partir de UML (Unified Modeling

Language), el cual finalmente será la carta de navegación para la construcción del

esquema de las bases de datos de las ontologías y su integración.

3.3.3 Componentes de arquitectura para la integración de los modelos de datos catastrales:

La integración de los modelos de datos catastrales se llevará a cabo a partir del desarrollo y construcción de la red de ontologías de la siguiente forma:

1. Para la planeación del desarrollo de la Ontología se utilizara el software “Neon Tool Kit” y su puggin “gOntt47”.GOntt es una herramienta para planificar y ejecutar proyectos de desarrollo de ontologías, para lo cual hace uso de plantillas orientadas a la planificación de desarrollos de ontologías basados en los escenarios propuestos por la metodología NeOn y genera las planificaciones de proyectos de desarrollo de ontologías en forma de diagramas Gantt.

2. Para el desarrollo de las ontologías se utilizara el software Protégé, el cual es de código abierto y libre, el formato final de las ontologías será en formato OWL o RDF. Posteriormente será necesario asociar otros recursos ontológicos identificados en la etapa de estudio de fuentes, para lo cual se llevará a cabo la construcción de la red de ontologías, para lo cual se hará uso igualmente del software Protégé.

3.3.4 Componentes de arquitectura para la generación de datos en formato RDF:

Para la conversión de los datos a RDF se tendrán dos frentes: uno que se encargará del aspecto espacial de los datos y el componente que se encargará de los datos alfanuméricos.

1. Componente Espacial: Para generar los atributos espaciales del RDF se va a utilizar es Geometry2RDF48. Esta es una librería desarrollada por el “Ontology

47 http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/technologies/61-gontt 48 http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/technologies/151-geometry2rdf

http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/technologies/61-gontt

http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/technologies/151-geometry2rdf

Capítulo III 73

Engeenering Group” de la Universidad Politécnica de Madrid. Sirve para generar ficheros RDF según el estándar GeoSPARQL a partir de información geométrica. Sin embargo, existe una versión preliminar que permite tener como fuente de datos archivos en formato shapefile. Para su aprovechamiento se descargó una versión personalizada a las particularidades de la ontología y a los datos en http://geosemantica.info/49

2. Componente Alfanumérico: Para la generación de otros atributos se plantea explorar el uso de “Open Refine” anteriormente llamada “Google Refine” y la extensión generada por el DERI “RDF Refine”. Google Refine es una herramienta para transformación de un formato a otro y refinamiento de datos. “RDF Refine” una extensión de “Open Refine” para exportarlos a datos formato RDF.

3.3.5 Componentes de arquitectura para el repositorio de los datos en formato RDF:

Como repositorio de los datos en RDF se hará uso de Parliament, que es un Triple Store y gestor de datos compatible con los estándares RDF, RDFS, OWL, SPARQL. Soporta consultas espaciales con el lenguaje SPARQL. Para su configuración se hará uso de un servidor web con sistema operativo Ubuntu.

3.3.6 Componentes de arquitectura para la configuración del sistema de publicación y vinculación de datos

Para la publicación y vinculación de los datos se realiza la configuración de dos entornos de trabajo:

1. Entorno de desarrollo y pruebas: Para la publicación de los datos y el uso del triple store se realiza la configuración de una máquina virtual con el sistema operativo Ubuntu 14.04. Allí se realiza la instalación de “parliament” y la configuración de los componentes requeridos para la publicación de la información.

2. Entorno de producción: Para la publicación de los datos se configura una cuenta

en “AWS Amazon50” que proporciona la capacidad de almacenamiento para la publicación de datos en la nube.

49 https://github.com/jasaavedra/shp2geosparql 50 http://aws.amazon.com/es/ec2/

http://geosemantica.info/

https://github.com/jasaavedra/shp2geosparql



Las herramientas de configuración en los entornos de desarrollo y producción para la

publicación de los datos:

Ubuntu versión 14.10 Parliament versión 2015 para sistema operativo de 64 bits Java versión 7 Navegador Google Chrome

En cuanto a la herramienta para la vinculación de los datos “Silk” que permite establecer los enlaces de la información a partir de comparación de textos homólogos en las dos fuentes de información a vincular.

Adicionalmente, se abordará una nueva versión “st-silk51” en cuya funcionalidad tiene asociada la extensión “geotools” que permite realizar comparación entre geometrías como por ejemplo “→está contenido”. Para el tipo de geometría puntual se basa en w3cgeo y para el tipo de geometría poligonal a partir de geoSPARQL.

3.3.7 Características técnicas del servidor

Para la ejecución de pruebas, así como la publicación de los datos se configuraron dos entornos, los cuales se trabajaron sobre el mismo equipo, con las siguientes características:

Tabla 3-21: Características equipo entorno de pruebas y producción

Características Equipo

Marca HP - Pavilion

Procesador AMD; 2,10 GHz

Tarjeta Gráfica Radeon (tm) HD – Dual Graphics

RAM 8 GB

Disco Duro 500

Los demás software para gestión y desarrollo de ontologías, generación de datos y vinculación se trabajaron de localmente.

51 https://github.com/psmeros/stSilk

Capítulo III 75

4. CAPÍTULO IV: DISEÑO Y MODELAMIENTO DE DATOS

En este capítulo se hace un análisis de las características de los modelos de datos oficialmente establecidos para el catastro nacional y para el catastro de la ciudad de Bogotá. Además se hace la caracterización del modelo de datos base para su homologación, el modelo “LADM” (Land Administration Domain Model), el cual fue parte del resultado de la investigación realizada en el anterior capítulo del presente proyecto de investigación; por medio de éste modelo de datos, se busca establecer el alcance para la estructuración de los tipos de datos geográficos y realizar el análisis entre los diferentes modelos objeto de estudio.

4.1 Modelo De Datos Catastral Nacional - IGAC

La Subdirección de Catastro ha centrado sus esfuerzos en los últimos años en el desarrollo del Sistema Nacional Catastral (SNC) cuyo proyecto actualmente se encuentra en la fase de implementación. Para el desarrollo del Sistema Nacional Catastral se tomó como base el modelo de datos oficialmente establecido por la Subdirección de Catastro resultado del trabajo conjunto entre las Direcciones Territoriales, Catastros Descentralizados y el Catálogo de Objetos del IGAC

4.1.1 Generalidades

Fuentes: La información fuente que alimenta el modelo de datos, es el resultante de los procesos catastrales de formación, actualización de la formación y conservación catastral de la información que se levanta en campo a partir de la actividad de reconocimiento predial.

Formato: La información se encuentra almacenada y estructurada en una base de datos corporativa centralizada.



Sistema: La base de datos centralizada que se encuentra sincronizada en los servidores de sede central IGAC ubicada en la ciudad de Bogotá, es manejada a partir de Oracle; en las Direcciones Territoriales ubicadas en las principales ciudades del país y en la Unidades Operativas de Catastro en diversos municipios, se maneja a partir de Postgresql. De esta forma, en las Direcciones Territoriales y Unidades Operativas de catastro trabajan en versiones realizadas por cada municipio, posteriormente se realiza la conciliación de las versiones a la versión default semanalmente, finalmente, se debe realizar la sincronización a la base centralizada.

Formato Modelo de Datos: El modelo se construyó en UML.

Unidad de producto: La información tanto urbana como rural es manejada a nivel de municipio.

Sistemas de referencia: La información del área urbana y corregimientos (con características urbanas) se encuentra en coordenadas planas locales referidas a Datum Magna Sirgas, por su parte la información del área rural se encuentra en coordenadas planas proyectadas a Datum Magna Sirgas.

Escalas: Para la información del área urbana y corregimientos se maneja escala 1:500; por su parte la información del área rural se maneja a escalas 1:25.000 y 1:10.000, de acuerdo a la disponibilidad de cartografía base suministrada por la Subdirección de Geografía y Cartografía, insumo para realizar el levantamiento físico catastral.

Elementos de evaluación de calidad: De acuerdo con las especificaciones técnicas de calidad NTC5043 y NTC5660 y las normas ISO 19113, ISO 19114 e ISO 19158, los elementos de calidad que se evalúan sobre la información geográfica catastral son los siguientes:

Totalidad: Se realiza la depuración de los predios que se encuentran tanto en

omisión como comisión; por un lado se revisa la completitud de la información respecto a la ortofoto y al insumo levantado en campo; por otra parte se realizan cruces comparativos a partir de los registros catastrales alfanuméricos con el fin de revisar la consistencia y garantizar “el dato único”; así, los predios que se encuentran en la base gráfica y ausentes en la alfanumérica corresponden a predios en comisión que deben ser revisados y depurados, y viceversa los predios que se encuentran ausentes en la base gráfica pero si existen en la base

Capítulo V 77

alfanumérica corresponden a predios omitidos que deben ser revisados y depurados.

Exactitud temática: Se evalúa la clasificación y consistencia de los atributos tanto cualitativos como cuantitativos de acuerdo a la información insumo que se levantó en campo en el proceso catastral respectivo.

Consistencia lógica Se evalúa la topología; por su parte los dominios y los formatos se tiene controlado a partir del modelo de datos implementado en la base de datos corporativa del SNC.

Exactitud de posición, para el área urbana se evalúa que la información se encuentre en la referencia espacial oficialmente establecida para cada municipio y que las manzanas coincidan posicionalmente con la ortofoto suministrada por la Subdirección de Geografía y Cartografía; por su parte, para el área rural se verifica que la información se encuentre en la referencia espacial oficialmente establecida y que la información se encuentre correctamente georeferenciada de acuerdo a las planchas 1:10.000 y 1:25.000 suministradas por la subdirección de geografía y cartografía.

Exactitud temporal se lleva un control de las vigencias catastrales de cada municipio de acuerdo a los procesos de formación, actualización y conservación.

Documentación: De acuerdo a las especificaciones técnicas de productos cartográficos, la NTC 5662 propone un formato, el cual es la base para cada uno de los productos cartográficos generados resultado de los procesos catastrales, de esta forma se alimenta un formato de especificación técnica para:

La carta catastral El plano predial rural El certificado plano El plano de conjunto Los planos de zonas homogéneas físicas y geoeconómicas urbanas y

rurales

Metadatos: Los metadatos de todos los productos cartográficos catastrales son diligenciados a través de la plataforma Swami 3.0 de acuerdo con la NTC 4611.

4.1.2 Catálogo de Objetos – IGAC (ICDE)

El modelo de datos catastral nacional se encuentra basado en el catálogo de objetos oficialmente establecido por la Subdirección de Geografía y Cartografía del IGAC en el marco de la Infraestructura Colombiana de Datos Espaciales ICDE, la cual constituye la fuente de documentación para el presente apartado:



El catálogo de objetos geográficos se encuentra conforme al estándar internacional ISO 19110 – Feature Catalogue Methodology. Está conformado por diez (10) temáticas, en las cuales se incluye la cartografía básica, catastro y las temáticas misionales del IGAC.

En el catálogo de objetos se contemplan los siguientes componentes: Tema, Grupos, Objetos, Asociaciones, Atributos, Dominios y Operaciones.

Tema: Aunque el estándar ISO 19110 no incluye el concepto de tema y grupo, éstos

se han mantenido para agrupar los objetos del catálogo por las temáticas de las IDE y facilitar la implementación de los modelos de datos para cada temática.

Figura 4-1: Temas del Catálogo de Objetos

Grupos: Los grupos definidos para el Tema “Catastro” de acuerdo al catálogo de

objetos:

Figura 4-2: Grupos del tema Catastro - Catálogo de Objetos

Objetos: Centraremos nuestra atención en el grupo “Área Catastral” puesto que

es a partir de este donde registra el resultado del levantamiento del catastro físico predial:

Capítulo V 79

Figura 4-3: Objetos del grupo Área Catastral - Catálogo de Objetos

Las características de los componentes: Atributos, Dominios, Asociaciones y Operaciones, aunque son establecidas oficialmente por el catálogo de objetos, se definen detalladamente en el modelo de datos.

4.1.3 Estructura General del Modelo de Datos Catastral Nacional – IGAC

El esquema de la base de datos para captura de información catastral nacional predial es replicado para cada municipio y se encuentra dividido en área urbana y área rural.

Con el fin de mantener la precisión en las medidas de los predios de la información correspondiente a las áreas urbanas, el Departamento de Geodesia de la Subdirección de Geografía y Cartografía generó orígenes locales en MAGNA SIRGAS para las cabeceras municipales y corregimientos de los 995 municipios bajo la custodia del IGAC.

El sistema de coordenadas para la información catastral del área rural es asociado a uno de los 6 orígenes MAGNA – SIRGAS oficialmente establecidos por el Departamento de Geodesia de la Subdirección de Geografía y Cartografía, estos son: Oeste – Oeste, Oeste, Central, Este, Este – Este y San Andrés.

Asociaciones: El modelo de datos establece las asociaciones entre los objetos desde un nivel superior hacia un nivel inferior: Sector–Barrio, Barrio–Manzana, Manzana–Terreno, Terreno–Construcción, Terreno–Unidad, Terreno–Nomenclatura Domiciliaria, Construcción–Unidad:



Figura 4-4: Asociación objetos área urbana – Modelo Datos Catastral Nacional Fuente: Instructivo Administración Base Datos Corporativa, Subdirección de Catastro - IGAC

Correspondientemente se establecen las asociaciones desde un nivel superior hacia un nivel inferior en el área rural: Sector–Vereda, Vereda–Terreno, Terreno–Construcción, Terreno–Unidad, Terreno–Nomenclatura Domiciliaria, Construcción–Unidad:

Figura 4-5: Asociaciones objetos área rural – Modelo Datos Catastral Nacional Fuente: Instructivo Administración Base De Datos Corporativa, Subdirección de Catastro - IGAC

Capítulo V 81

Atributos: A continuación se puede observar los atributos de los objetos y sus relaciones. El diccionario de datos con las definiciones detalladas de los objetos, sus atributos y relaciones se pueden encontrar en el Anexo B - Análisis de modelos de datos catastrales.

Figura 4-6: Atributos objetos área urbana – Modelo Datos Catastral Nacional Fuente: Instructivo Administración Base Datos Corporativa, Subdirección de Catastro - IGAC



Figura 4-7: Atributos objetos área rural – Modelo Datos Catastral Nacional Fuente: Instructivo Administración Base Datos Corporativa, Subdirección de Catastro - IGAC

Dominios y Operaciones: Dominios y estructura establecida para los atributos de cada uno de los objetos geográficos catastrales. Es de aclarar que los atributos y tipos de datos aplican tanto para el modelo establecido en el área urbana como para el área rural:

Capítulo V 83

Tabla 4-1: Estructura Sector Urbano/Rural:

Tabla 4-2: Estructura Barrio Urbano:

Tabla 4-3: Estructura Manzana/Vereda:

Tabla 4-4: Estructura Terreno Urbano/Rural:

Tabla 4-5: Estructura Construcción Urbana/Rural:

Tabla 4-6: Estructura Unidad Urbana/Rural:



Tabla 4-7: Estructura Nomenclatura Domiciliaria Urbana/Rural:

Tabla 4-8: Estructura Zona Homogénea Física Urbana/Rural:

Tabla 4-9: Estructura Zona Homogénea Geoeconómica Urbana/Rural:

4.2 Modelo de Datos Catastral de Bogotá - UAECD

4.2.1 Generalidades

Anteriormente la Unidad Administrativa Especial de Catastro Distrital (UAECD) llevaba a cabo los procesos de edición de la información cartográfica catastral en el software ArcInfo, sin embargo se inició una labor de migración de la información y aplicativos manejados por la entidad y a partir del mes de septiembre de 2011 se inician sus labores oficialmente con el software ArcGIS. Para lo cual se generó la base de datos corporativa para la administración de la información del catastro físico predial de la ciudad de Bogotá.

4.2.2 Catálogo de Objetos del Mapa de Referencia

Bajo la necesidad de conformar una fuente única de datos espaciales básicos para la ciudad de Bogotá D.C., IDECA focalizo sus esfuerzos en generar un conjunto organizado de datos que denomina “Mapa de Referencia”. Para documentar la estructura de los datos

Capítulo V 85

que contiene el mapa de referencia se generó el catálogo de objetos geográficos52, el cual constituye la fuente de documentación para el presente apartado:

Tema Catastro: Los temas que componen este catálogo

Figura 4-8: Temas catálogo de objetos Mapa de Referencia de Bogotá

Grupos: Está compuesto por dos grupos: Área Catastral y Nomenclatura:

Figura 4-9: Grupos catálogo de objetos Mapa de Referencia de Bogotá

Objetos: El grupo “Área Catastral” agrupa 4 objetos ligados directamente con el

espacio físico de la ciudad: Sector catastral, Manzana, Lote y Construcción. El grupo “Nomenclatura Domiciliaria” contiene el objeto Placa.

Figura 4-10: Objetos catálogo de objetos Mapa de Referencia de Bogotá

52http://www.ideca.gov.co/sites/default/files/files/Proyectos/MR/EI%20%20Cat%C3%A1logo%20de%20Objetos%20MR%20V4_2_2012.pdf



4.2.3 Modelo de Datos del Mapa de Referencia

El modelo de datos del mapa de referencia de para también fue documentado a partir del

Catálogo de Objetos Geográficos53:

Atributos, Asociaciones y Dominios: A continuación se detallan, los

atributos, asociaciones, dominios y operaciones para los objetos geográficos catastrales del mapa de referencia de Bogotá Sector Catastral: Espacio geográfico en que se divide el área urbana y rural.

Su extensión geográfica es el Distrito Capital. Tiene tres subtipos: Barrio, Vereda y Mixto.

Tabla 4-10: Ficha objeto Sector Catastral

53http://www.ideca.gov.co/sites/default/files/files/Proyectos/MR/EI%20%20Cat%C3%A1logo%20de%20Objetos%20MR%20V4_2_2012.pdf

Capítulo V 87

Manzana: Espacio geográfico donde se agrupa un conjunto de lotes con o sin construcción los cuales se encuentran delimitados por espacio público y/o accidentes naturales. Su extensión geográfica es el área urbana y de expansión del Distrito Capital.

Tabla 4-11: Ficha objeto Manzana



Lote: Mínima unidad geográfica donde se ubica uno o más predios ya sean

urbanos o rurales. Su extensión geográfica es el Distrito Capital.

Tabla 4-12: Ficha objeto Lote

Capítulo V 89

Construcción: Edificación con cubierta de carácter permanente asociada a un lote destinada a proteger contra la intemperie a personas, animales o bienes. Su extensión geográfica es el Distrito Capital.

Tabla 4-13: Ficha objeto Construcción

Placa: Información de referencia de la ciudad, para predios, construcciones comerciales, recreacionales, culturales y habitacionales en general.

Tabla 4-14: Ficha objeto Placa



Para la ubicación espacial de los elementos se considera importante considerar los objetos localidad y municipio, los cuales hacen parte del grupo de Entidad Territorial y Unidad Administrativa:

Localidad: Información de referencia de la ciudad, para predios, construcciones comerciales, recreacionales, culturales y habitacionales en general.

Capítulo V 91

Tabla 4-15: Ficha objeto Localidad

Municipio:

Tabla 4-16: Ficha objeto Municipio



4.3 MODELO “Land Administration Domain Model” – LADM (ISO: 19152)

Esta norma internacional define un modelo de datos para el ámbito de la administración de la tierra. El propósito del LADM no es reemplazar a los sistemas existentes, sino proporcionar un lenguaje formal para describirlos, de manera que sus similitudes o diferencias se puedan entender mejor. A continuación se documentan los aspectos más representativos de la norma ISO 19152 – LADM54:

4.3.1 Objetivos LADM:

Esta norma internacional proporciona un modelo de referencia para la administración del territorio con dos objetivos:

1. Proporcionar una base extensible para el desarrollo y refinamiento de sistemas eficientes y efectivos de administración del territorio.

2. Permitir la comunicación entre los interesados involucrados, tanto dentro de un mismo país como entre diferentes países, basándose en un vocabulario común (ontología).

4.3.2 Funciones LADM:

El segundo objetivo de LADM es relevante para la creación de servicios de información normalizados en un contexto nacional o internacional, donde la semántica de la administración del territorio se tiene que compartir entre regiones o países. Con el fin de dar cumplimiento a este objetivo, esta norma tiene las siguientes funciones:

1. Define un modelo de referencia para el ámbito de la administración del territorio (Land Administration Domain Model – LADM) que cubre los componentes básicos de la información relacionada con la administración del territorio (incluyendo el agua, el terreno y los elementos sobre y bajo la superficie terrestre).

2. Proporciona un modelo conceptual abstracto con cuatro paquetes relacionados con:

Los interesados (personas y organizaciones)

Las unidades básicas administrativas, los derechos, las responsabilidades y las restricciones (derechos de propiedad)

Las unidades espaciales (parcelas, el espacio jurídico de los edificios y las redes de servicios)

54 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=51206


Capítulo V 93

Las fuentes espaciales (levantamientos) y representaciones espaciales (geometría y topología)

3. Proporciona una terminología para la administración del territorio, basada en varios sistemas nacionales e internacionales, siendo lo más simple posible para que en la práctica sea útil. La terminología permite tener una descripción común de diferentes prácticas formales o no formalizadas y de los procedimientos de varias jurisdicciones.

4. Proporciona una base para los perfiles nacionales y regionales.

5. Permite la combinación de información de administración del territorio procedente de diferentes fuentes de manera coherente.

4.3.3 Características de LADM:

Adicionalmente LADM tiene otras características valiosas a la hora de modelar la administración del territorio, que si bien son bastante interesantes, se encuentran fuera del campo de aplicación en el presente proyecto de investigación:

1. La interferencia con leyes de administración del territorio (nacional) que pueden tener implicaciones jurídicas.

2. La construcción de bases de datos externas con datos de los interesados, direcciones, valoración, usos del suelo, coberturas, red física de servicios, archivos y datos de impuestos. Sin embargo, el LADM proporciona clases estereotipadas para estos conjuntos de datos para indicar qué elementos del conjunto de datos espera el LADM para esas fuentes externas y su disponibilidad.

3. El modelado de los procesos de administración del territorio.

4.3.4 Clases Básicas LADM:

Esta norma establece un modelo estándar que quiere lograr la armonización de una parte básica de todos los sistemas catastrales existentes (core model), de tal manera que permita que cada catastro conserve sus prácticas y procedimientos al tiempo que se permite el intercambio de la información entre los distintos sistemas catastrales. El núcleo del LADM se basa en 4 clases básicas:

1. LA_Party: Las instancias de esta clase son “los interesados”.

2. LA_RRR. Las instancias de las subclases de LA_RRR son: “derechos, restricciones o responsabilidades”.

3. LA_BAUnit. Las instancias de esta clase son “unidades básicas administrativas”.

4. LA_SpatialUnit. Las instancias de esta clase son “unidades espaciales”.



4.3.5 Paquetes LADM:

LADM cuenta con cuatro paquetes que son cada uno independientes entre sí y a través de un lenguaje UML se adaptan a las distintas situaciones. En la siguiente figura se muestra los paquetes de LADM:

Figura 4-11: Paquetes de LADM y sus clases Fuente: ISO 19152 - Modelo para el Ámbito de la Administración del Territorio (LADM)

1. LA_Party (interesados): Define a la persona u organización que juega un papel

en una transacción de derechos (interesado).

Interesados Unidades

Administrativas

Unidades

Espaciales

Fuentes y

representaciones

espaciales

Capítulo V 95

2. Administrative Package (unidad básica administrativa): Las clases principales son LA_RRR y LA_BUnit. La primera tiene tres sub clases que hacen referencia a responsabilidad, derecho y restricción sobre un elemento. La segunda hace referencia a una entidad administrativa, sujeta a registro (por ley), o inscripción (por derecho no formalizado o derecho consuetudinario u otra relación social de tenencia), consistente en cero o más unidades espaciales (spatial units) a la que se asocia como entidad completa, (uno o más) derechos (por ejemplo, derecho de propiedad o derecho de uso del terreno, responsabilidades o restricciones. Un buen ejemplo es una unidad de condominio que comprende dos unidades espaciales (por ejemplo, un apartamento y un garaje que pertenecen a la misma persona).

3. Spatial Unit Package (Unidad espacial): El nivel hace referencia a un conjunto de unidades espaciales, con una coherencia geométrica, topológica o temática.

4. Surveying and Representation Subpackage (Topografía y representación): Los puntos se utilizan como referencia para describir la posición de una unidad espacial. Además, un punto se puede usar para definir un vértice de un lado de una parcela 3D. Se puede usar también como un punto para definir el Inicio, fin o un vértice de un lindero.

Considerando que en el alcance del presente proyecto de investigación se aborda el aspecto físico del catastro se centra la atentación en el paquete de “Unidad Espacial”:

Spatial Unit Package (Unidad espacial)

Figura 4-12: Clases del paquete Spatial Unit Fuente: ISO 19152 - Modelo para el Ámbito de la Administración del Territorio (LADM)

Parcela

Grupo Parcelas

(ZHF, ZHG,

Municipio etc.

La parcela puede agrupar a su vez

otras sub-parcelas

Unidad de

edificación

Red de

servicios

Nivel (capa)

Se puede crear una jerarquía a

base de zonas que agrupan zonas



El nivel hace referencia a un conjunto de unidades espaciales, con una coherencia geométrica, topológica o temática. A partir de la clase LA_SpatialUnitGroup es posible crear jerarquías de agrupación para las unidades espaciales.

Además es posible observar en la siguiente figura el detalle de las relaciones entre el paquete de “unidad espacial” con respecto a los otros paquetes de LADM y el detalle de sus clases y atributos.

Figura 4-13: Detalle de clases y relaciones paquete Spatial Unit Fuente: ISO 19152 - Modelo para el Ámbito de la Administración del Territorio (LADM)

Capítulo V 97

El detalle de los atributos y clases usados en la caracterización de los modelos de datos con respecto al paquete “Unidad Espacial” de LADM se encuentra en el documento en el Anexo B: Análisis del modelo de datos catastral Nacional y Distrital respecto al estándar internacional de administración de la tierra LADM

4.4 Especificación de alcance

4.4.1 Tipos de datos:

De acuerdo con los mandatos establecidos en la reglamentación y las políticas definidas por el gobierno “prosperidad para todos” debe ser pública toda la información catastral a excepción de la que tenga restricción por habeas data.

De acuerdo a lo anterior, para el caso específico del presente proyecto de investigación, se pretende hacer pública y disponible para consulta la información geográfica catastral a excepción del nombre de los propietarios. Por esta razón se propone trabajar con el tipo de objetos del modelo LADM llamado “Spatial Unit Group” con el fin de realizar la homologación respecto al estándar internacional.

4.4.2 Extensión geográfica:

Los datos seleccionados para trabajar en el proyecto piloto se determinaron basados en los siguientes criterios:

Criterios de selección de datos del Catastro Nacional (IGAC):

1. Un sector catastral de un municipio con vigencia catastral reciente, es decir

que tenga fecha de actualización catastral reciente 2. Un sector catastral de un municipio colindante con la ciudad de Bogotá para

visualizar la continuidad de la información 3. Un sector catastral de un municipio que presente buenas condiciones en

cuanto a calidad de la información se refiere, con el fin de evitar procesos de depuración, ya que es importante que la información publicada tenga características mínimas de calidad topológica.

Criterios de selección de datos para el Catastro Distrital (UAECD)

En cuanto a los datos para el Catastro Distrital, se identificaron tres zonas de trabajo:

1. Un sector colindante con el municipio de Soacha por la integración y continuidad de la información

2. Dos sectores continuos de la zona central de Bogotá, en la cual es posible encontrar diversidad de sitios de interés, esto es importante en la etapa de vinculación con otras fuentes de datos en la web.



Figura 4-14: Sub-conjunto de datos catastrales Fuente: Propia

Tabla 4-17: Relación subconjunto de datos catastrales:

Capítulo V 99

4.4.3 Metadatos

La información fuente de publicación tanto de catastro nacional como distrital cuenta con sus respectivos metadatos:

Metadato Mapa de referencia de Bogotá:

La descripción detallada del metadato es posible consultarlos a través del siguiente link:

http://metadatos.ideca.gov.co/geoportal/catalog/search/resource/details.page?uuid=%7B8F6AF03F-438B-49EE-BAD9-7D6533A97E5C%7D

Figura 4-15: Metadato mapa de referencia de Bogotá Fuente: IDECA, http://metadatos.ideca.gov.co/geoportal/catalog/search/resource/

Metadato Cartografía Catastral de Soacha:

La descripción detallada del metadato es posible consultarlos a través del siguiente link: http://srvmetadata.igac.gov.co/swami/app/#



http://metadatos.ideca.gov.co/geoportal/catalog/search/resource/

http://srvmetadata.igac.gov.co/swami/app/



Figura 4-16: Metadato mapa catastral digital urbano municipio de Soacha Fuente: IGAC, http://srvmetadata.igac.gov.co/swami/app/#

4.4.4 Usuarios Potenciales:

Disponer la información catastral en la web es útil para:

Autoridades catastrales: con el fin de solucionar la problemática existente con el tema de límites municipales y departamentales.

Entidades públicas: Las entidades que trabajan a nivel predial, esto con el fin de generar mejores prácticas de planeación y ordenamiento territorial. Dichas entidades son usuarias hoy día de ésta información. A nivel Distrital se difunde la información a través de webservices, pero a nivel nacional actualmente todo se gestiona a través de convenios interinstitucionales.

Entidades privadas: En la actualidad la tecnología, páginas web, desarrollos, proyectos, entre otros, tienden a incorporar el componente geográfico en sus bases de datos alfanuméricas para la toma de decisiones.

Público en general: El flujo para solicitar la información catastral será mucho más ágil, eficiente y unificado.


Capítulo V 101

4.5 Análisis de modelos de datos

Se realizó el análisis de los modelos catastrales Nacional y Distrital cuyo resultado fue materializado en el archivo anexo “Análisis modelos de datos”; sin embargo apoyados de los diagramas de clases de la siguiente figura veremos algunas de las diferencias más significativas de estructura y semántica:

Figura 4-17: Diferencias modelos de datos catastral Nacional y Distrital Fuente: Propia

De manera general se encontraron diferencias entre los dos modelos de datos catastrales en cuestión de objetos, campos, atributos, dominios, tipos de datos e incluso diferencias semánticas en los nombres de los objetos y sus atributos. El detalle de esta comparación y para fines de planificación y desarrollo de las ontologías se realizó un paralelo entre los modelos de datos Catastro Nacional y Catastro Distrital con respecto al modelo Internacional de Administración de la Tierra LADM.

Es posible consultar el resultado del paralelo de los modelos de datos del catastro Nacional, Distrital y LADM en el Anexo B del presente documento:

Anexo B. Análisis Modelo Datos Nacional - Distrital - LADM



4.5.1 Diferencias modelo de datos catastral Nacional y Distrital:

Algunas de las diferencias más significativas entre los modelos de datos catastrales son las siguientes:

1. En el modelo de datos Catastral Nacional se contempla a partir de la capa Unidad inventariar los datos en altura de las construcciones tanto para predios sometidos como no sometidos al régimen de propiedad horizontal, apuntando a un catastro 3D. En el modelo de datos Catastral Distrital en la capa Construcción se maneja el atributo número de pisos controlando los datos de altura de forma alfanumérica más no espacial. En el perfil LADM para Colombia se incluye la clase Unidad para hacer posible la consulta de la información existente a este respecto y dejar abierta la posibilidad para a futuro homologar la clase en el caso que Catastro Distrital quisiera implementar un catastro tridimensional.

2. En el modelo de datos Catastral Nacional dadas las condiciones de orígenes locales para la información urbana y orígenes proyectados para el área rural se manejan por cada objeto la información urbana independiente de la información rural como se evidenció en el apartado anterior. Por su parte en el modelo de datos Catastral Distrital dadas las condiciones de origen local tanto para el área urbana como rural se maneja un solo consolidado de la información tanto urbana como rural para cada objeto dado que gracias a la adopción de los estándares de producción cartográfica ya se maneja un solo sistema de referencia para la cartografía del Distrito.

3. Relacionado al ítem anterior, se observa que en el modelo de datos Catastral Distrital se maneja una tipificación de sector urbano, rural y mixto para la misma capa de información “Sector Catastral”, dado que los sectores son formados en concordancia con los desarrollos de la ciudad. Por su parte en el modelo de datos Catastral Nacional se manejan dos capas de información correspondientes al Sector independiente Urbano y Rural y no contempla la tipificación Mixto dada la división cartográfica por el tema de escalas y proyecciones.

4. En el modelo de datos Catastral Distrital se manejan las siguientes tipificaciones para la “Placa Domiciliaria”: Principal, Secundaria, Incluye, Adicional PH, Provisional DSU, estas tipificaciones no son manejadas en el modelo de datos Catastral Nacional. Se realiza la homologación de manera general, se incluyen las tipificaciones manejadas en el modelo Distrital en caso que a futuro de deseen implementar dichas tipificaciones en el modelo Nacional.

5. En el modelo de datos Catastral Nacional la capa de Información Nomenclatura Domiciliaria Urbana y Rural corresponde a tipo de geometría lineal; por su parte, la capa Placa Domiciliaria en el modelo de datos Catastro Distrital es manejada con tipo de geometría puntual. Se realizó la homologación a partir del modelo ontológico de acuerdo al estándar de tipo de geometría puntual. Este aspecto es una característica cartográfica que

Capítulo V 103

por tema de representación, sin embargo en el modelo ontológico es indiferente el aspecto de la representación dado que GeoSPARQL tiene la capacidad de consultar cualquier geometría.

6. A manera general los nombres de las capas de información, los nombres de los

campos, los tipos de datos, dominios, estructura, etc. son diferentes en los modelos de datos catastral Nacional y Distrital. Se realiza la homologación de los modelos nacionales respecto a un estándar internacional y en el modelamiento de las ontologías definir las correspondencias que permiten establecer la relación entre los diferentes objetos, campos, atributos, tipos de datos y dominios.

4.6 Modelado LADM_CO

LADM_CO es un perfil de LADM para Colombia, sobre el cual se realiza la homologación de los modelos de datos catastrales Nacional y Distrital.

Figura 4-18: UML con modelo conceptual de la Ontología “LADM_CO” Fuente: Propia

El modelo LADM corresponde a un estándar internacional de administración de la tierra que modela de manera muy general, por lo cual en su implementación cada país suele hacer un perfil acoplado a las necesidades particulares para el modelado de sus datos geográficos.



Así, los modelos de datos catastrales nacional y distrital manejan en sus metodologías internas características particulares que no son visibles en LADM, este caso se refleja por ejemplo en la tipificación del sector catastral para el catastro distrital; por tal motivo se realizó un modelado que permitiera articular detalladamente los dos modelos de datos catastrales nacionales involucrados en el proyecto piloto con el estándar internacional LADM, evitando la pérdida de los detalles particulares manejados por los modelos nacionales.

El resultado de la homologación de los modelos de datos catastrales nacionales respecto a un estándar internacional tiene como valor agregado el mejoramiento de las posibilidades de integración con información de otros, proporcionando facilidades de acceso y compresión de la información. Permite además unificar criterios de consulta, búsqueda, análisis y procesamiento a partir de conjuntos de datos integrados.

LADM_CO (modelo LADM para Colombia) se constituye a partir de este momento en la carta de navegación para la construcción del esquema de las bases de datos de las ontologías y la integración de los modelos de datos.

4.6.1 Catálogo de Objetos LADM_CO

Para el modelado LADM_CO se definió el catálogo de objetos de acuerdo a los siguientes parámetros:

- Nombre - Tipo de geometría - Padre - Definición - Atributos - Relaciones - Reglas

Estos aspectos fueron documentados para los siguientes objetos geográficos:

- Perímetro Urbano - Sector catastral - Barrio - Vereda - Manzana - Terreno - Construcción - Nomenclatura Domiciliaria - Unidad

El detalle del resultado del catálogo de objetos para el modelo LADM_CO es posible consultarlo en el Anexo C del presente proyecto de investigación.

Capítulo V 105

5. CAPÍTULO V: DESARROLLO DE ONTOLOGÍAS

En este capítulo se muestran las actividades que comprenden la construcción de la red de ontologías.

5.1 Desarrollo de Ontologías

Como resultado de la etapa de análisis de fuentes de información y estado del arte en el tercer capítulo de este proyecto, se encontró que la metodología NeOn55 es una metodología que propone un flujo para la construcción y gestión de ontologías; establece escenarios para el desarrollo de ontologías desde ceros, la reutilización de recursos ontológicos y no ontológicos y la construcción de redes de ontologías. Así, el flujo a seguir basados en la metodología NeOn se observa en la siguiente figura:

Figura 5-1: Flujo para el desarrollo y gestión de ontologías (NeOn Metodology) Fuente: Propia

55 http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/methodologies/59-neon-methodology



5.1.1 Especificación de requerimientos

Para el desarrollo de las ontologías, se levantó inicialmente la especificación de requerimientos para las ontologías a desarrollar en correspondencia con los modelos de datos geográficos catastrales establecidos a nivel Nacional y Distrital; en la especificación de requerimientos se definió:

- Propósito de la ontología - Alcance - Nivel de formalidad - Usuarios - Usos - Requerimientos funcionales - Requerimientos no funcionales - Ple-glosario de términos - Esquema preliminar de la red de ontologías

El detalle de la especificación de requerimientos de ontologías es posible consultarlo en el Anexo D del presente documento.

5.1.2 Conceptualización y formulación

El siguiente paso es la conceptualización de la ontología a partir de la formulación y planteamiento de los escenarios previamente establecidos por la metodología NeOn; para lo cual, fue necesario identificar los escenarios a los cuales dieran lugar las características establecidas en la especificación de requerimientos.

La Metodología NeOn propone nueve escenarios en los cuales se enmarcan todas las posibles situaciones que se pueden presentar a la hora de desarrollar y/o gestionar ontologías:

Escenario 1- Desde la especificación de la aplicación: Este escenario plantea el desarrollo de la ontología desde cero, es decir desde la especificación de requerimientos de la ontología, posteriormente se debe hacer una búsqueda de recursos ontológicos y no ontológicos para la respectiva planeación de las actividades de construcción de la ontología, después se debe hacer la conceptualización y enmarcar los escenarios contemplados para su desarrollo y finalmente viene el desarrollo e implementación de la misma.

Escenario 2 - La reutilización y reingeniería de los recursos no ontológicos (NOR): Plantea la posibilidad identificar recursos no ontológicos que cumplan con las características de la ontología a desarrollar para llevar a cabo el proceso de reutilización para construir la red de ontologías.

Escenario 3 - La reutilización de los recursos ontológicos (OR): Se pueden identificar recursos ontológicos que tengan relación con la ontología que se desea desarrollar, estos recursos pueden ser reutilizados para construir la red de ontologías.

Capítulo V 107

Escenario 4 - La reutilización y re-ingeniería de los recursos ontológicos (OR): Se plantea no solamente la identificación de los recursos ontológicos a reutilizar, sino además la reorganización o modificación de ellos de acuerdo con las necesidades evidenciadas en la especificación de requerimientos.

Escenario 5 - La reutilización y la fusión de los recursos ontológicos: Plantea la posibilidad de crear un nuevo recurso ontológico a partir de la fusión de los recursos ontológicos previamente identificados.

Escenario 6 - Reutilización, la fusión y re-ingeniería de los recursos ontológicos: Se plantea la posibilidad no solo la posibilidad de crear un nuevo recurso de ontologías a partir de la fusión de otras con las características requeridas en la especificación, sino además la reorganización o modificación de las mismas.

Escenario 7 - Reutilización de los patrones de diseño de ontologías (ODPs). Este escenario plantea la reutilización de los recursos de las ontologías desde su diseño que se encuentran en repositorios denominados ODPs.

Escenario 8 - Reestructuración de recursos ontológicos: Para el tema en cuestión, el termino reestructuración es sinónimo de modularizar, podar, extender y/o la espacialización de los recursos ontológicos previamente a ser integrados en la red de ontologías.

Escenario 9 - Localización de recursos ontológicos: Se plantea la posibilidad de crear ontologías multilingües adaptándola a otras lenguas.

De acuerdo con la descripción detallada para cada uno de los escenarios establecidos por la metodología NeOn, se realizó un análisis respecto a las características previamente definidas en la especificación de requerimientos, de lo cual se identificó que las necesidades de este proyecto se enmarcan en los siguientes escenarios:

Tabla 5-1: Escenarios contemplados en la especificación de requerimientos



5.1.3 Formalización y planeación

Una vez definidos los escenarios a aplicar se realizó la formalización y planeamiento de las actividades para el desarrollo de las ontologías.

Como resultado de la planeación se obtuvieron seis fases, a partir de las cuales se contemplan los cuatro escenarios seleccionados de la metodología NeOn:

Figura 5-2: Fases desarrollo de ontologías para los escenarios contemplados Fuente: Propia

La planeación del desarrollo de las ontologías se llevó a cabo por medio de la herramienta NeOn Toolkit y su plugin gOntt. A partir de esta, se plantearon los tiempos y actividades para el desarrollo de las ontologías en correspondencia a los escenarios previamente definidos en el marco de la metodología NeOn:

Figura 5-3: Planeación para el desarrollo de ontologías (NeOn Toolkit) _Parte 1 Fuente: Propia, Herramienta NeOn Toolkit - gOntt

Capítulo V 109

Figura 5-4: Planeación para el desarrollo de ontologías (NeOn Toolkit) _Parte 2 Fuente: Propia, Herramienta NeOn Toolkit – gOntt

Las actividades detalladas para cada una de las fases planteadas:

Tabla 5-2: Detalle de actividades en cada fase de desarrollo de las ontologías



5.1.4 Implementación y desarrollo de las ontologías:

Para el desarrollo de las ontologías y definir el esquema de la base de datos se hizo uso del software Protégé plataforma desktop versión 4.3 desarrollado por la Universidad de Standford. A partir de este fue posible definir los vocabularios y lenguaje específicos para cada uno de los recursos de los modelos de datos a definir en las ontologías.

La implementación y desarrollo de las ontologías contempla dos etapas generales del proceso:

1. Desarrollo de ontologías para los recursos no ontológicos: Corresponde al desarrollo de las ontologías a partir de los modelos de datos catastrales y su documentación:

El modelo de datos catastral Nacional Modelo de datos catastral Distrital

2. Construcción de la red de ontologías: Corresponde a la creación y vinculación

de una red de ontologías, la cual es el resultado de las ontologías desarrolladas en la etapa anterior sumado a la reutilización de los recursos ontológicos previamente identificados como potencialmente vinculables en el capítulo 3 del presente proyecto:

Homologación modelos nacionales con LADM_CO: En este apartado se aplicará el escenario número 3 (E3) de la metodología NeOn, ya que se hará la reutilización del recurso ontológico LADM para la homologación de los Modelos Catastrales. Por su parte, los modelos catastrales Nacional y Distrital corresponden a recursos no ontológicos, los cuales son base para la aplicación del escenario número 1 (E1) de la metodología NeOn que comprende el desarrollo del ceros de la ontología.

Asociación con GeoCOL: GeoCOL corresponde a un recurso ontológico el cuál sería reutilizado en esta etapa del proceso (E3).

Asociación con GeoSPARQL: GeoSPARQL también corresponde a un recurso ontológico a ser reutilizado en esta etapa del proceso (E3).

Patrón de URIs de las Ontologías: Inicialmente es necesario definir el patrón de URIs de las ontologías, para lo cual se plantea una URI básica, a su vez, los recursos ontológicos estarán referenciados con una URI que contenga el nombre del tipo de elemento presente en la ontología:

La Uri Básica: http://datos.igac.gov.co/

Uri de las clases en la ontología: http://datos.igac.gov.co/{tipo_elemento_ontologia}/{identificador}

http://datos.igac.gov.co/

http://datos.igac.gov.co/%7btipo_elemento_ontologia%7d/%7bidentificador%7d

Capítulo V 111

Ontología Modelo de Datos Catastral Nacional (IGAC) Para la construcción de la ontología para el modelo de datos catastral nacional se definieron las siguientes características que harán parte del esquema de la ontología.

1. URI de la ontología:

El propósito de la web semántica con el modelamiento y desarrollo ontológico de objetos geográficos es proporcionar o dotar de una estructura bien definida a los recursos y asociar a éstos un leguaje y vocabularios apropiados que permitan establecer vínculos a través de sus relaciones. Unos de los componentes principales en el desarrollo de la ontología es la definición de la URI base para la ontología y las clases de la ontología. Así, la URI base definida para la ontología y las clases del Modelo de Datos Catastral Nacional es: http://datos.igac.gov.co/ontologias/catastro/igacsnc.

2. Entidades o Clases:

Para cada uno de los objetos del modelo de datos Catastral Nacional se define la clase, sus propiedades y relaciones para construir el esquema de la base de datos de la ontología. Los objetos para los cuales se definirá una clase del esquema son:

Perímetro Urbano Sector Urbano y Rural Manzana y Vereda Terreno Urbano y Rural Nomenclatura Domiciliaria Urbana y Rural Construcción Urbana y Rural Unidad Urbana y Rural

A continuación se ilustra como ejemplo el resultado de la definición de la clase, propiedades, atributos y relaciones para el objeto “Terreno Urbano”:

Figura 5-5: Definición de la Clase Terreno Urbano: Fuente: Propia, Herramienta Protégé

http://datos.igac.gov.co/ontologias/catastro/igacsnc



Para la definición de la clase “Terreno Urbano” se consideraron las siguientes características:

Asociación de una etiqueta de visualización Descripción de la clase con el fin de tener actualizado el diccionario de datos. Como parte de las subclases de la ontología se definen las relaciones de la clase

respecto a las demás clases de los objetos de la base de datos. Con el fin de aplicar el escenario número 9 de NeOn Metodology (aplicación de

ontologías multilingües) y considerando que la idea es que la ontología tenga consulta a nivel internacional se establecen las características de la clase en el idioma Español e Inglés. En este punto es posible observar otro valor agregado con el desarrollo del presente trabajo de investigación, ya que en la actualidad en Colombia aún no es posible establecer modelos de datos de creación, consulta y visualización multilingüe de acuerdo a la necesidad.

Es posible visualizar las propiedades de las subclases indicando las relaciones de la Clase “Terreno Urbano” respecto a las demás clases definidas en el esquema de la base de datos:

Figura 5-6: Propiedades y relaciones de la Clase Terreno Urbano: Fuente: Propia, Herramienta Protégé

Como resultado de la definición de las subclases se estableció la relación de la Clase “Terreno Urbano”:

Una “Construcción Urbana” pertenece exactamente a un “Terreno Urbano” Una “Manzana Urbana” está formada por algunos “Terreno Urbano” Una “Nomenclatura Domiciliaria” pertenece exactamente a un “Terreno Urbano” Un “Terreno Urbano” es parte de exactamente una “Manzana Urbana” Un “Terreno Urbano” tiene algunas “Unidad Urbana” Un “Terreno Urbano” tiene algunas “Nomenclatura Domiciliaria Urbana”} Un “Terreno Urbano” tiene algunas “Construcción Urbana” Una “Unidad Urbana” pertenece a máximo un “Terreno Urbano”

Capítulo V 113

Adicionalmente se creó la subclase área y se define como tipo “double” teniendo presente la gran importancia que tiene este atributo en el tema catastral.

3. Propiedades de los atributos:

Para cada Clase “Terreno Urbano” del modelo de datos Catastral Nacional se definen los campos, atributos, tipos de datos, dominios, etc.:

Código del terreno Código de la manzana Número de Subterráneos Código anterior del terreno

En la Figura 5-7 se observan las propiedades asociadas al campo “código del terreno”:

Asociación de una etiqueta de visualización al campo Descripción del campo con el fin de tener actualizado el diccionario de datos. Se establece el tipo de dato Se agrega la característica para el campo tanto en español como en inglés. Adicionalmente en la definición del esquema de la base de datos se crean los

vínculos que evidencian las relaciones que se definieron para los objetos.

Figura 5-7: Atributos de las clases: Fuente: Propia, Herramienta Protégé

En el ejemplo de la figura anterior es posible evidenciar que el código del terreno hace parte del dominio Terreno, cuando se da click al vínculo lo llevará a la clase del Objeto Terreno. En general la esencia de los modelos ontológicos es para cada recurso de la ontología se asocia una URI que posteriormente permitirá establecer los vínculos con los recursos de las demás ontologías.



Es importante resaltar en este apartado como un valor agregado que nos ofrece el esquema de la base de datos de la ontología, es que si un mismo campo es requerido para más de una capas independiente, en el modelo de la base de datos solamente es necesario definirlo una sola vez y será asociado a las capas que sea necesario y con las cuales tenga relación. Un ejemplo es el código del terreno, el cual es requerido en las capas: Terreno, Construcción, Unidad, Nomenclatura Domiciliaria; en los modelos de datos actuales este campo debería aparecer cuatro veces, una vez por cada capa, mientras en el esquema de la base de datos ontológica solamente se define una vez y es asociado a las capas que sea necesario.

En la siguiente figura se puede observar las propiedades para el campo “código anterior del terreno” es posible visualizar el tipo de dato y el dominio.

Figura 5-8: Propiedades de los Atributos Fuente: Propia, Herramienta Protégé

4. Propiedades de las relaciones entre las clases:

Además de las características de los atributos, se establecen las propiedades de las relaciones que pueden existir entre las clases, se define la ontología multilingüe (inglés, español) y se define su relación inversa.

Capítulo V 115

Figura 5-9: Relaciones entre las clases de la ontología: Fuente: Propia, Herramienta Protégé

Adicionalmente es posible visualizar todas las posibles clases en las cuales se estableció el tipo de relación definida para cada clase:

Figura 5-10: Relación “está formado por” entre las clases modelo nacional: Fuente: Propia, Herramienta Protégé



Figura 5-11: Relación “es parte de” entre las clases modelo nacional: Fuente: Propia, Herramienta Protégé

Figura 5-12: Relación “pertenece a” entre las clases modelo nacional: Fuente: Propia, Herramienta Protégé

Capítulo V 117

Figura 5-13: Relación “tiene” entre las clases modelo nacional: Fuente: Propia, Herramienta Protégé

En cuanto a las relaciones establecidas en el esquema de la base de datos de la ontología, es importante resaltar dos aspectos:

Inicialmente las relaciones “está formado por”, “es parte de”, “pertenece a” y “tiene” corresponde a relaciones definidas de acuerdo a estándares internacionales y por ende ya existen URIs modeladas como ontologías para ellas. Dichas relaciones fueron reusadas en el desarrollo de las ontologías, en caso de requerir una relación no definida como estándar, será posible crearla para brindar recursos de reúso a la comunidad activa en este medio.

El segundo aspecto se evidencia en el proceso de construcción de la red de ontologías, ya que es posible extender las relaciones creadas en la etapa de desarrollo a las ontologías reutilizables que hacen parte de la red y establecer equivalencias entre las mismas.

5. Visualización gráfica de la Ontología:

Es posible visualizar en la siguiente figura el resultado de la ontología para el modelo de datos catastral nacional:



Figura 5-14: Esquema de Ontología Modelo de Datos Catastral Nacional: Fuente: Propia, Herramienta Protégé

Ontología Modelo de Datos Catastral Distrital (BOGOTÁ)

Para la construcción de la ontología para el modelo de datos catastral distrital al igual que para el modelo nacional se definieron las siguientes características que harán parte del esquema de la ontología.

1. URI de la ontología:

La URI base definida para la ontología y las clases del Modelo de Datos Catastral Distrital es: http://datos.igac.gov.co/ontologias/catastro/bogota

2. Entidades o Clases:

Para cada objeto del modelo de datos Catastral Distrital se define la clase, sus propiedades y relaciones para construir el esquema de la base de datos de la ontología. Los objetos para los cuales se definirá una clase del esquema son:

Sector Catastral: Urbano, Rural, Mixto Manzana Lote Construcción Placa Catastral: Principal, Secundaria, Adicional PH, Provisional DSU Uso

Capítulo V 119

A continuación se ilustra el resultado de la definición de la clase, propiedades, atributos y relaciones para el objeto “Lote”.

Figura 5-15: Definición de la Clase Lote: Fuente: Propia, Herramienta Protégé

Para la definición de la clase “Lote” se consideraron homólogamente las mismas características que para el esquema del modelo nacional; sin embargo se adicionó un ítem correspondiente al “código” considerando que cada objeto geográfico en este modelo es manejado a partir del mismo.

Igualmente se establecieron las relaciones respecto de las demás clases del esquema de la base de datos de la ontología.

Como resultado de la definición de las subclases se estableció la relación de la Clase “Lote” (Ver Figura 5-16):

Un “Lote” tiene algunas “Construcción” Un “Lote” tiene como mínimo una “Placa Domiciliaria” Un “Lote” es parte de una “Vereda” Un “Lote” es parte de una “Manzana” Una “Construcción” pertenece exactamente a un “Lote” Un “Uso” pertenece a algunos “Lote” Una “Vereda” está formada como mínimo por un “Lote” Se creó la subclase área y se define como tipo “double”



Figura 5-16: Propiedades y relaciones de la Clase Lote: Fuente: Propia, Herramienta Protégé

3. Propiedades de los atributos:

Para cada Clase “Lote” del modelo de datos Catastral Distrital se definen los campos, atributos, tipos de datos, dominios, etc. Los campos definidos en el modelo de datos catastral distrital para el Objeto Lote son los siguientes, los cuales igualmente son definidos en el esquema de la ontología.

Identificador único del lote Disperso Identificador del lote disperso Unidad Predial Código de la manzana

En cuanto a los atributos de la clase Lote, se agregaron las propiedades, se agregó el “Código” de acuerdo a la definición en el modelo de datos catastral Distrital.

Capítulo V 121

Figura 5-17: Atributos de la Clase Lote: Fuente: Propia, Herramienta Protégé

Igualmente es posible visualizar las propiedades atributivas, tipos de datos, dominio, rango,etc para los campos de la clase “Lote”

Figura 5-18: Propiedades Atributos de la Clase Lote: Fuente: Propia, Herramienta Protégé

4. Propiedades de las relaciones entre las clases:

Las relaciones definidas para las clases son las mismas que se revisaron en la construcción del esquema de la base de datos catastral nacional:



“está formado por” “es parte de” “pertenece a” “tiene”

Para ellas también se define una etiqueta y la ontología multilingüe al igual que en los demás recursos.

Las relaciones entre las clases en el modelo de datos catastral Distrital son las siguientes:

Figura 5-19: Relación “está formado por” entre las clases del modelo distrital: Fuente: Propia, Herramienta Protégé

Figura 5-20: Relación “es parte de” entre las clases del modelo distrital: Fuente: Propia, Herramienta Protégé

Capítulo V 123

Figura 5-21: Relación “pertenece a” entre las clases del modelo distrital: Fuente: Propia, Herramienta Protégé

Figura 5-22: Relación “tiene” entre las clases del modelo distrital: Fuente: Propia, Herramienta Protégé

Habiendo definido las mismas relaciones que en el esquema de base de datos de la ontología nacional y distrital, será posible establecer sus relaciones de acuerdo al estándar internacional definido en el modelo de datos de la ontología.

5. Visualización gráfica de la Ontología:

Posteriormente es posible visualizar el resultado de la ontología para el modelo de datos catastral nacional:



Figura 5-23: Esquema de Ontología Modelo de Datos Catastral Distrital: Fuente: Propia, Herramienta Protégé

Ontología LADM_CO La construcción de la ontología LADM_CO se basa en el modelado UML, resultado del capítulo anterior, y el catálogo de objetos que lo describe. El cual es un perfil de LADM para dar un mayor nivel de detalle según las particularidades del catastro Nacional y Distrital:

Figura 5-24: Modelado UML LAMD_CO Fuente: Propia

Capítulo V 125

De acuerdo al modelo de la ontología base definido para LADM_CO, se hace una especialización de las clases del modelo LADM (SpatialUnit, SpatialUnitGroup, etc.), teniendo en cuenta que aborden todo lo contenido en los modelos catastrales nacional y distrital (manzana, barrio, etc.). Así en la siguiente figura es posible observar por ejemplo las subclases “Terreno” y “Construcción” haciendo parte de la clase “SpatialUnit”.

Figura 5-25: Clases del Modelo LADM_CO Fuente: Propia, Herramienta Protégé

En el modelo LADM_CO se definieron igualmente los atributos, dominios y tipos de datos, así como las relaciones establecidas entre los objetos. En la siguiente figura, es posible visualizar el campo “Numero de Pisos” para la Subclase “Construcción”

Figura 5-26: Atributos, dominios y tipos de datos Modelo LADM_CO Fuente: Propia, Herramienta Protégé



Las relaciones entre los objetos del modelo catastral:

Figura 5-27: Relaciones Ontología Modelo LADM_CO Fuente: Propia, Herramienta Protégé

En la siguiente figura, es posible observar las relaciones de la SubClase “Terreno” en el modelo LADM_CO:

Figura 5-28: Relaciones SubClase “Terreno” Fuente: Propia, Herramienta Protégé

5.2 Construcción de Red de Ontologías:

Para la construcción de la red de ontologías se tienen los siguientes recursos:

Capítulo V 127

1. Ontología Modelo de Datos Catastral Nacional: Corresponde a la ontología desarrollada que contempla el modelo de datos catastral establecido a nivel nacional por el IGAC.

2. Ontología Modelo de Datos Catastral Distrital: Corresponde a la ontología desarrollada que contempla el modelo de datos catastral establecido a nivel distrital por la UAECD.

3. Ontología LADM_CO: Corresponde al perfil LADM para Colombia. Es el resultado de un modelo de datos catastral basado en el estándar internacional LADM adaptado con las particularidades de los modelos catastrales nacionales.

4. Ontología GeoCOL56: Resultado de la búsqueda de recursos potencialmente vinculables (capítulo 3). Ontología entidades territoriales y administrativas de Colombia

5. Ontología GeoSPARQL: Ontología de vocabularios resultado de la búsqueda de recursos potencialmente vinculables (capítulo 3).

El proceso de construcción de la red de ontologías contempla dos actividades generales, las cuales finalmente se verán reflejadas en la ontología “mapping”:

Proceso de homologación: Inicialmente la homologación del modelo LADM_CO con las ontologías catastrales Nacional y Distrital. La información fuente requerida para el primer proceso, que corresponde al de homologación es la siguiente: Modelo ontológico catastral Nacional Modelo ontológico catastral Distrital Modelo catastral LADM_CO

Asociación de recursos ontológicos: En segunda instancia, asociar el resultado de la homologación en LADM_CO con los recursos ontológicos encontrados en el capítulo de diagnóstico para la construcción de la red. Ontología GeoSPARQL57 Ontología GeoCOL 58

5.2.1 Proceso de homologación

Posterior al detalle indicado para el modelo LADM_CO, procedemos al proceso de homologación:

56 SAAVEDRA VELÁZQUEZ, Jhonny Alexis. Linked Data Geográfico conforme a geosparql – caso de aplicación División Territorial y Administrativa de Colombia. Tesis de Maestría. Universidad Politécnica d Madrid. 2011 57 http://www.opengeospatial.org/standards/geosparql 58 SAAVEDRA VELÁZQUEZ, Jhonny Alexis. Linked Data Geográfico conforme a geosparql – caso de aplicación División Territorial y Administrativa de Colombia. Tesis de Maestría. Universidad Politécnica d Madrid. 2011




Para esto necesario importar la ontología catastral nacional y distrital a LADM_CO y establecer las equivalencias a partir de las relaciones y los resultados establecidos en el capítulo cuatro de modelamiento de datos:

Figura 5-29: LAMD_CO: Importación Ontologías Catastral Nacional y Distrital Fuente: Propia, Herramienta Protégé

Además se realiza la asignación de las equivalencias a nivel de clase y propiedad, a partir de las cuales será posible establecer las relaciones de homologación entre los modelos de datos:

Figura 5-30: Ejemplo de equivalencias homologación del modelo LADM_CO ↔ IGAC/UAECD Fuente: Propia, Herramienta Protégé

Capítulo V 129

En la figura anterior es posible observar la equivalencia entre las capas de información:

Plac: Corresponde a la capa de placa domiciliaria en Catastro Bogotá RNomenclaturaDomiciliaria: Corresponde a la capa de Nomenclatura Domiciliaria

Rural en Catastro Nacional UNomenclaturaDomiciliaria: Corresponde a la capa de Nomenclatura Domiciliaria

Urbana en Catastro Nacional

Lo que anteriormente correspondía a tres clases independientes, dos en el modelo de ontología Nacional (Nomenclatura domiciliaria urbana y rural) y una en el modelo de ontología Distrital (Placa domiciliaria), ahora se integra en la Clase “Address”.

Figura 5-31: Visualización Gráfica de la Clase “Address” Fuente: Propia, Herramienta Protégé

A nivel de atributos, dominios, tipos de datos también se establecen las equivalencias respectivas que son heredadas de la clase principal, aquí se hace uso del id (primary key) definido para cada clase en los modelos de datos:

Figura 5-32: Equivalencias de atributos Fuente: Propia, Herramienta Protégé



En la figura anterior se establecen las equivalencias para la clase “Barrio”, allí se observan su homologación con el sector catastral urbano en el modelo Nacional y Distrital, asimismo se realiza la homologación del Id Principal para cada modelo de datos en “barrioId”.

5.2.2 Asociación de ontologías al resultado de la homologación:

Para la construcción de la red de ontologías es necesario asociar los recursos ontológicos identificados en el capítulo tres del presente proyecto al resultado de la homologación. El resultado de todo el proceso de construcción es consolidado en la ontología “mapping”.

La información fuente para la asociación de ontologías a la red corresponde a la ontología homologada resultado de la etapa anterior, GeoSPARQL y GeoCOL:

GeoSPARQL59

GeoSPARQL es una extensión del lenguaje de consulta SPARQL para datos espaciales, Asi, proporciona finalmente el lenguaje de consultas para los datos espaciales en formato RDF.

En la siguiente figura se observan los recursos asociados a la ontología GeoSPARQL:

Figura 5-33: Recursos asociados a la Ontología GeoSPARQL

59 http://www.opengeospatial.org/standards/geosparql


Capítulo V 131

La ontología GeoSPARQL es un recurso ontológico encontrado en la etapa de análisis y diagnóstico y es reusado en esta etapa del proceso para asociarlo a la red de ontologías para la temática catastral “mapping”.

GeoCOL60

Corresponde a una ontología resultado de un trabajo de investigación de maestría aplicado a la información geográfica de las entidades administrativas y territoriales de Colombia. En la siguiente figura se observan las clases definidas para la ontología GeoCOL:

Figura 5-34: Ontología GeoCOL

La ontología GeoCOL también fue encontrada en la etapa de análisis y diagnóstico de fuentes, la cual es reusada para la construcción de la red de ontologías para la temática catastral.

Para la construcción de la red de ontologías se asocian las ontologías GeoSPARQL y GeoCOL a la ontología “mapping” la cual ya contempla el resultado de la homologación de los modelos catastrales.

60 SAAVEDRA VELÁZQUEZ, Jhonny Alexis. Linked Data Geográfico conforme a geosparql – caso de aplicación División Territorial y Administrativa de Colombia. Tesis de Maestría. Universidad Politécnica d Madrid. 2011



Figura 5-35: Asociación geoSPARQL a la ontología mapping

El resultado final de la construcción de la red de ontologías se observa en la siguiente figura, allí se encuentra el resultado de la homologación de los modelos ontológicos catastrales Nacional y Distrital con respecto al modelo LADM_CO; además de la asociación con los modelos ontológicos geoCOL y geoSPARQL.

Figura 5-36: Construcción de la Red de Ontologías Fuente: Propia

Capítulo V 133

El detalle de las ontologías usadas y generadas en el presente capítulo se puede consultar en formato OWL en el link de descarga: http://geosemantica.info/ontologias/Ontologias.zip.

5.3 Depuración iterativa de la ontología:

Finalmente, fue necesario realizar la evaluación y control de calidad de la red de ontologías generadas, para lo cual se realizó una depuración iterativa hasta garantizar el cumplimiento de los requerimientos establecidos en la especificación de alcance para los modelos ontológicos y acorde a los modelos de datos catastrales nacionales.

http://geosemantica.info/ontologias/Ontologias.zip

Capítulo VI 134

6. CAPÍTULO VI: GENERACIÓN DE DATOS, PUBLICACIÓN Y VINCULACIÓN

El capítulo seis se encuentra orientado inicialmente a las actividades tendientes a generar los datos base en formato RDF que comprende los vocabularios a utilizar de acuerdo a la definición del esquema de la base de datos de las ontologías; para lo cual se establece la especificación de requerimientos, metadatos y la conversión a formato RDF de la información geográfica catastral. En el segundo apartado, se procede a la publicación de los datos para lo cual se hace uso del Triple Store y finalmente se realiza la vinculación de los datos catastrales generados y publicados en formato RDF, con respecto a datos geográficos que se encuentran en la nube.

6.1 Generación de datos

En este apartado se llevó a cabo la definición del alcance de datos, características de su estructura en RDF (patrón de URI’s y vocabularios a utilizar) y determinación de elementos a vincular.

Para efectos de la documentación del presente proyecto de investigación se toma como ejemplo de referencia el procedimiento realizado para la clase UTerreno. El detalle del resultado del componente alfanumérico y espacial de todos los datos en formato RDF con las URIs y vocabularios asociados para las demás clases del esquema de la base de datos de la ontología se puede consultar en el link: http://ec2-52-24-37-29.us-west-2.compute.amazonaws.com:8080/parliament/

6.1.1 Especificación de requerimientos

Para la definición de la estructura de los datos a ser generados se levantó la especificación de requerimientos para lo cual se tomó como base la NTC 5662-Especificaciones técnicas de productos geográficos. En la especificación de requerimientos se detallan los siguientes aspectos, los cuales pueden ser consultados en el Anexo E del presente documento:

1. La descripción de la especificación: - Términos, definiciones y abreviaturas - Alcance

2. Identificación del conjunto de datos

- Identificación del producto

http://ec2-52-24-37-29.us-west-2.compute.amazonaws.com:8080/parliament/

http://ec2-52-24-37-29.us-west-2.compute.amazonaws.com:8080/parliament/

Capítulo VI 135

- Contenido y estructura de los datos

3. Sistemas de referencia

4. Calidad de los datos

5. Entrega del conjunto de datos - Forma de entrega - Medio de entrega

6. Perfil de metadato

6.1.2 Diagrama del proceso de generación de datos:

En la siguiente figura el posible visualizar el flujo de procesos que comprende el proceso

de conversión del componente espacial y alfanumérico de los datos a formato RDF.

Figura 6-1: Diagrama del proceso de conversión de datos a formato RDF Fuente: Propia

Basados en el esquema de la base de datos de las ontologías (capítulo anterior), se construye el esquema en formato RDF tanto del componente espacial como alfanumérico apoyados en las herramientas “shp2GeoSparql” y “Open Refine” respectivamente, para lo cual se realiza la asociación del patrón de URIs a utilizar y asociación de los vocabularios de las ontologías. El resultado corresponde a archivos planos que contienen tanto las geometrías como los atributos de la información catastral cuyo indexado finalmente permitirá realizar consultas espaciales conforme al lenguaje de consulta RDF SPARQL.



6.1.3 Patrón de URIs de los datos

La web semántica plantea que cada recurso de la web este referenciado a través de una URI y establecer vínculos que permitirán al usuario final encontrar los datos relacionados publicados.

La Uri Básica de la ontología: http://datos.igac.gov.co/

6.1.4 Conversión de datos a formato RDF

Para la conversión de los datos a formato RDF es necesario realizar procesos independientes para el componente espacial y el alfanumérico dado que el componente alfanumérico tiene más herramientas consolidadas como open refine que permite el tratamiento de los datos con características alfanuméricas. Por su parte, respecto a la publicación como Open Linked Data Geográfico del componente espacial, para la conversión de las “geometrías” se hace uso de herramientas para generar RDF en GeoSPARQL estándar que permite realizar consultas de análisis espacial conforme al lenguaje SPARQL.

Componente Alfanumérico:

Para generar la información alfanumérica a formato RDF se hizo uso de la aplicación Open Refine61, a partir de esta aplicación web es posible generar los datos en RDF según los vocabularios establecidos en la red de ontologías.

Para construir el esquema RDF del componente alfanumérico de los datos (ejemplo clase UTerreno) se consideran las siguientes características:

1. Inicialmente es asociada la URI Base de la ontología

2. Para evitar escribir por cada recurso de los datos la URI de la ontología, se asigna un prefijo:

snc:http://datos.igac.gov.co/ontologias/catastro/igacsnc/

3. Se debe añadir la clase “Terreno Urbano” como tipo RDF snc:UTerreno

4. Para establecer una llave de enlace con los demás datos, el “primary key” del elemento es asignado como una URI para poder

codigoTerreno as URI

61 http://openrefine.org/download.html

http://datos.igac.gov.co/

Capítulo VI 137

5. Son añadidas las propiedades definidas en el esquema de la base de datos de la ontología para cada uno de los campos existentes en la clase “Terreno Urbano”. Se hace la asignación del esquema definido en la ontología a cada campo existente en el archivo contenedor de la información alfanumérica de los datos catastrales.

snc:codigoTerreno codigo

Figura 6-2: Esquema RDF componente alfanumérico Clase “Terreno Urbano” Fuente: Propia, Herramienta Open Refine

El resultado del componente alfanumérico en formato RDF con los vocabularios y URIs asociados para la clase “Terreno Urbana” se ilustra en la siguiente figura.

Figura 6-3: Salida RDF componente alfanumérico Clase “Terreno Urbano” Fuente: Propia



Componente Espacial:

En cuanto al componente espacial se usó un desarrollo realizado en un trabajo de investigación de maestría “Linked Data conforme a GeoSPARQL”62, el cual permite asociar las características de las URIs base y los vocabularios requeridos al componente espacial en formato RDF con el fin de realizar consultas geográficas en el lenguaje sparql.

Inicialmente es necesario definir algunos aspectos inherentes a la información del archivo en formato shape el cual contiene la información espacial de la clase “Terreno Urbano” y además establecer algunas características previamente definidas en el esquema de la base de datos de la ontología:

Figura 6-4: Esquema RDF componente espacial Clase “Terreno Urbano” Fuente: Propia

El resultado del componente espacial en formato RDF con los vocabularios y URIs asociados para la clase “Terreno Urbano” se ilustra en la siguiente figura:

Figura 6-5: Salida RDF componente espacial Clase “Terreno Urbano” Fuente: Propia

62 https://github.com/jasaavedra/shp2geosparql

Capítulo VI 139

6.1.5 Depuración de datos en formato RDF

Posterior al proceso de conversión de los datos a formato RDF, se requiere realizar un proceso de depuración de calidad, para lo cual se debe garantizar la correcta asociación del patrón de URIs y los vocabularios asignados para las clases definidas en las ontologías cuyas características deben corresponder al modelamiento para cada capa de información geográfica catastral y sus atributos.

6.2 Publicación de datos

Para la publicación de los datos se configura una cuenta en “AWS Amazon63” que proporciona la capacidad de almacenamiento para la publicación de datos en la nube. Allí se realiza la configuración de una máquina virtual con el sistema operativo Ubuntu 14.04., se realiza la instalación del triple store “parliament” y la configuración de los componentes requeridos para la publicación de la información.

Para la publicación de los datos se debe inicializar el triple store a través del terminal de ubuntu es posible acceder a la interfaz de Parliament, para lo cual accedemos a un navegador preferiblemente Google Chrome y agregamos la URL requerida:

https://ec2-52-24-37-29.us-west-2.compute.amazonaws.com:8080/parliament/

La salida para publicación de datos para Parliament por default corresponde al puerto 8080.

Figura 6-6: Interfaz del Triple Store Parliament 2015

Fuente: Propia, Herramienta Parliament

63 http://aws.amazon.com/es/ec2/



Parliament es un triple store de alto rendimiento y razonador diseñado para Web Semántica. Parliament TM es una marca comercial de BBN Tecnologies, Inc., y es muy usado para el parlamento de información en formato OWL64. Parliament es uno de los pocos triple store que permiten realizar consultas conforme al lenguaje GeoSPARQL, provee una interfaz a partir de la cual se pueden realizar diversas operaciones con los datos como insertarlos y exportarlos, consultarlos, realizar consultas con el vocabulario Sparql para formato RDF y explorar a través de ellos.

Para ingresar los datos en formato RDF el menú de Operations escogemos la opción “Insert Data”.

Es de recordar que la para la conversión de los datos a formato RDF se realizaron procesos independientes para el componente espacial y alfanumérico. En este apartado se centra en la publicación de los datos de los dos componentes, parliament posee una funcionalidad que posteriormente permitirá realizar el indexado de las geometrías asociadas a la información alfanumérica con el fin de garantizar nuevamente la integridad de la información con su característica espacial.

6.2.1 Publicación Componente Alfanumérico:

Inicialmente cargaremos el componente alfanumérico en formato *.ttl el cual es un archivo de intercambio con RDF

Figura 6-7: Insertando datos componente alfanumérico Clase “Terreno Urbano”


Es posible explorar en el repositorio de los datos publicados en la interfaz de parliament. Como se explicó previamente el formato RDF permite la descripción conceptual de los

64 Parliament TM User Guide, Ian Emmons, Marzo 2014

Capítulo VI 141

recursos web, mediante la creación de sentencias en forma de tripletas que representan información acerca de los recursos en forma de grafos.

Figura 6-8: Tripleta RDF

En la siguiente figura es posible observar los Id de los Terrenos, URIs y atributos para la Clase “Terreno Urbano”:

La primera columna corresponde al “Sujeto” Id Terreno La segunda columna corresponde al “Predicado” URIs La tercer columna corresponde al “Objeto” Atributos

Figura 6-9: Tripleta RDF Componente Alfanumérico Clase Terreno Urbano


En el siguiente ejemplo (Figura 6-10) se refleja más al detalle la composición de la tripleta RDF para la consulta de un objeto específico:

Se observa la declaración para el código de terreno = “257540104000000020027000000000”. La tripleta se encuentra conformada por “Sujeto”, “Predicado” y “Objeto”:

Subject: El sujeto corresponde al código del terreno para el cuál se realiza propiamente la consulta. codigoTerreno = “257540104000000020027000000000”.

Predicate: Está conformado por las URIs establecidas para la consulta de los atributos asociados al terreno urbano consultado.

Sujeto Objeto Predicado



Object: Comprende los datos o atributos asignados para cada campo asociado al

terreno urbano consultado.

Figura 6-10: Tripleta RDF Componente Alfanumérico Terreno = “257540104000000020027000000000”.


6.2.2 Publicación Componente Espacial:

Posteriormente insertamos los datos que comprenden el componente espacial en formato *.rdf.

Figura 6-11: Insertando datos componente espacial Clase “Terreno Urbano”


Para el caso del componente espacial en la Figura 6-12 el Id de terreno consultado 257540104000000070025000000000, se tiene:

Primera columna corresponde al Sujeto Las URIs asociadas (segunda columna) corresponden al predicado Las geometrías (tercera columna) corresponden al Objeto

Capítulo VI 143

Figura 6-12: Tripleta RDF Componente Espacial Clase Terreno Urbano


En la figura 6-13 es posible ver el detalle para un objeto específico consultado para el componente espacial. Se observa la declaración para el Terreno = “257540104000000070025000000000”. La tripleta se encuentra conformada por “Sujeto”, “Predicado” y “Objeto”:

Subject: El sujeto corresponde al código del terreno para el cuál se realiza propiamente la consulta.

Predicate: Está conformado por las URIs establecidas para la consulta de las geometrías asociados al terreno urbano consultado.

Object: Comprende las geometrías asignadas asociadas al terreno urbano

consultado.

Figura 6-13: Publicación tripleta RDF Componente Espacial Terreno




Teniendo presente que los componentes gráficos y alfanuméricos son insertados a la web de manera independiente, se realiza el indexado para lograr hacer las consultas espaciales conforme al lenguaje GeoSPARQL.

El indexado de los datos se realizó igualmente con el uso de Parliament:

Figura 6-14: Publicación tripleta RDF Componente Espacial Terreno


6.3 Vinculación de Datos

Este apartado comprende la vinculación de los datos para lo cual se tomará como fuente los catastrales publicados como tripleta RDF resultado de la etapa anterior; la segunda fuente de datos comprende otros datos previamente publicados e identificados en el capítulo tres en la etapa de diagnóstico de recursos potencialmente vinculables como lo son DBpedia y GeoCOL.

Capítulo VI 145

Figura 6-15: Vinculación de datos catastrales con otros datos

Fuente: Propia

El proceso de vinculación comprende tres etapas a seguir: inicialmente la creación del espacio de trabajo, en segundo lugar el análisis de las fuentes de datos y finalmente la vinculación de los mismos.

Figura 6-16: Proceso de Vinculación

Fuente: Propia



6.3.1 Creación del Proyecto de Vinculación “WorkSpace”

Para la vinculación de los datos, inicialmente se creó un espacio de trabajo “workspace” el cuál se denominó “Ontología1”.

El proyecto contiene:

- Todos los prefijos de URI’s utilizados - La lista de fuentes de datos - Lista de tareas a vincular

Para este caso, aunque se realizó la vinculación con dos fuentes de datos diferentes DBpedia y GeoCOL, es posible consolidar todo en un solo proyecto.

Figura 6-17: Creación del espacio de trabajo “Workspace”

Fuente: Propia, Herramienta st-Silk

Figura 6-18: Propiedades de Vinculación Fuente de Datos Geográfica Catastral “GeoCatastro”


Capítulo VI 147

Además se deben crear los Dataset por cada fuente de datos a vincular, inicialmente para la fuente de datos geográfica catastral se definen las propiedades que contiene los recursos necesarios para recuperar sus entidades en la vinculación:

- EndPoint URI: Corresponde a la URI del punto final de SPARQL - Graph URI: Corresponde a las instancias de una gráfica especifica (Para este

caso no aplica) - Retry Count: Corresponde al número de veces para reintentar la conexión - Retry Pause: El tiempo que debe esperar entre reintentos de conexión

Figura 6-19: Creación de Datasets para fuente de datos


6.3.2 Fuentes de Datos

Inicialmente se llevó a cabo un análisis de los recursos potencialmente vinculables con el fin de establecer el tipo de vínculos a establecer tanto gráfica como alfanuméricamente entre las fuentes de datos.

Como resultado del capítulo tres, se identificaron algunos recursos que pueden tener relación con los datos catastrales y ser potencialmente vinculables. Existen algunos conjuntos de datos con componente geográfico que actualmente se encuentran en la web como “Linked Data” tales como DBpedia y GeoCOL.

Es de resaltar que en la actualidad no existe ninguna fuente de datos geográficos catastrales publicados como open linked data geográfico, el presente proyecto corresponde a la primera aproximación en esta temática. Es necesario realizar el análisis acerca de la relación existente de los datos catastrales publicados con respecto a cada fuente de datos potencialmente vinculable para establecer un enlace y hacer posible su vinculación.

DBpedia:

Comprende la publicación de los datos de Wikipedia como RDF. En este conjunto de datos se publicó información geográfica de los sitios de interés de diversos lugares del mundo.



Con el fin de vincular los datos geográficos catastrales con los puntos geográficos de DBpedia, es posible establecer una relación entre los sitios de interés que se encuentran contenidos en determinado lote catastral.

Además, es posible realizar algunas consultas de contenencia por inferencia haciendo uso de las ontologías:

Cuántos puntos o sitios de interés se encuentran contenidos en determinado barrio Cuál punto o sitio de interés se encuentra localizado en un lote

Al igual que para la fuente de datos geográfica catastral “GeoCatastro”, se establecen las propiedades de vinculación para la fuente de datos de DBpedia:

Figura 6-20: Propiedades de Vinculación Fuente de Datos DBpedia


Una vez definidos los recursos necesarios para la fuente de datos, éstos son asociados al espacio de trabajo:

Capítulo VI 149

Figura 6-21: Recursos asociados a las fuentes de datos a vincular


GeoCOL GeoCOL corresponde a la primera iniciativa de publicación de datos geográficos como Linked Open Data para el caso Colombiano. Es el resultado de un trabajo de investigación de maestría de la Universidad Politécnica de Madrid, el cual se basa en la publicación de datos geográficos conforme al lenguaje de consultas GeoSPARQL y proporciona un caso de aplicación con la publicación de datos geográficos correspondientes a la División Administrativa y Territorial de Colombia; es el primer avance de datos espaciales que involucra el tipo de geometría poligonal, ya que previamente sólo se evidenciaban avances para el tipo de geometría puntual, en su mayoría para sitios de interés.

Para lograr la vinculación de la información geográfica catastral con GeoCOL se identificó las siguientes relaciones de homologación:

Inicialmente entre la capa espacial correspondiente a “Perímetro Urbano” por parte

de los datos catastrales y su homólogo de vinculación corresponde a la capa “Área Urbana” de GeoCOL.



Las capas espaciales correspondientes a Barrio y UBarrio tanto en el modelo de

datos catastral de Bogotá y el Nacional correspondientemente; con respecto a la capa espacial “Barrio” que hace parte de la división administrativa en GeoCOL.

Además se pueden establecer relación de contenencia espacial identificando los barrios (información catastral) que se encuentran en un área municipal (entidades administrativas y territoriales)

Igualmente, se establecen las propiedades de vinculación para la fuente de datos de GeoCOL:

Figura 6-22: Propiedades de Vinculación Fuente de Datos GeoCOL


Una vez definidos los recursos necesarios para la fuente de datos, éstos son asociados al espacio de trabajo:

Capítulo VI 151

Figura 6-23: Recursos asociados a las fuentes de datos a vincular


6.3.3 Generando Vínculos

Para la vinculación de los datos se hizo uso de dos versiones de la herramienta de vinculación:

La vinculación de los datos catastrales a GeoCOL a través de la herramienta silk, por medio de la normalización de textos homólogos en las dos fuentes de información.

La vinculación de los datos catastrales con DBpedia a través de la extensión geotools de st-silk por medio de la relación de contenencia de los puntos de interés asociados a la información con tipo de geometría poligonal en los datos catastrales. Igualmente se establecerá análisis de contenencia entre la información de GeoCOL que corresponde a entidades territoriales administrativas y financieras y el perímetro y barrio de la información catastral.



Vinculación: Información Geográfica Catastral ↔ DBpedia

Para la vinculación de los datos catastrales con DBpedia se ha establecido la relación de contenencia: los sitios de interés con geometría puntual se encuentran contenidos en los lotes y barrios de la información catastral con tipo de geometría poligonal.

Relación de contenencia “Sitios Interés” (DBpedia) →”Terreno/Lote” (IGAC/UAECD)

Figura 6-24: Relación de contenencia “Sitios Interés” (DBpedia) → “Terreno/Lote” (IGAC/UAECD)

Fuente: Propia

Es posible identificar los objetos espaciales que permitirán establecer una relación para el enlace entre las dos fuentes de información. El objeto puntos de interés de DBpedia estarán contenidos en cada una de las capas con geometría poligonal de la información catastral Nacional y Distrital.

Figura 6-25: Enlazado datos catastrales ↔ DBpedia

Fuente: Propia

Capítulo VI 153

Para la vinculación de las tareas es necesario especificar los enlaces de referencia, además de las propiedades de vinculación para cada fuente de datos. Para esto se requiere indicar el nombre del Dataset construido como recurso de vinculación y la restricción de la fuente en correspondencia a la relación de análisis espacial previamente definida:

Figura 6-26: Propiedades de Vinculación


Es necesario establecer un link por cada relación encontrada en el análisis de las fuentes de datos.

Figura 6-27: Link1: Geo Catastro - DBpedia


Además de la visualización gráfica de la vinculación, es posible acceder a operadores que permitirán definir las reglas de vinculación. Los operadores disponibles son:

- Transformación: Aplica transformación a todos los datos entrantes - Comparación: Evalúa la similitud entre las fuentes de datos - Agregación: Agrega valores a las fuentes de datos



Para el caso específico del presente proyecto sólo fue necesario aplicar operadores de comparación.

Figura 6-28: Visualización Gráfica de la Vinculación


Vinculación: Información Geográfica Catastral ↔ GeoCOL

Para la vinculación de la información geográfica catastral con los datos publicados a través de GeoCOL es necesario generar el enlace con datos de tipo de geometría poligonal. La relación identificada entre las dos fuentes de datos corresponde a la información espacial del “área urbana” definida en GeoCOL ya que hace parte del modelo de datos de la División Administrativa y Territorial para Colombia, por su parte el “perímetro urbano” correspondientemente en el modelo de datos catastral de Sistema Nacional Catastral. Además es posible evidenciar relación espacial de contenencia a través de los barrios contenidos en determinada entidad administrativa y territorial.

Para el proceso de vinculación se requiere realizar un trabajo previo de normalización en los textos sobre la información fuente a vincular, con el fin de establecer la homologación para los enlaces:

Capítulo VI 155

Homologación capa “Perímetro Urbano” (IGAC) →”Área Urbana” (geoCOL) Figura 6-29: Homologación datos catastrales UPerimetro ↔ GeoCOL

Posterior a la homologación de los textos se establece el enlace para las capas de información fuente.

Figura 6-30: Enlazado datos catastrales ↔ GeoCOL

Se especifican los enlaces de referencia y las propiedades de vinculación para cada fuente de datos. Para esto se indica el nombre del Dataset como recurso de vinculación y la restricción de la fuente:



Figura 6-31: Propiedades de Vinculación


Se establece el link para la relación de contenencia existente entre los municipios de las Entidades Territoriales y Administrativas y los lotes de la información catastral:

Figura 6-32: Link2: GeoCatastro – GeoCOL


Existe un valor agregado al vincular los datos geográficos catastrales a otros conjuntos de datos del ámbito geográfico previamente publicados como open linked data geográfico bajo el contexto de la web semántica, puesto que permitirá sumar la información geográfica catastral a la red compartida de datos geográficos en la nube.

Capítulo VI 157

Figura 6-33: Publicaciones Linked Open Data

En la figura anterior, es posible observar las publicaciones y productores en el contexto de Linked Open Data a nivel internacional, la franja amarilla corresponde a publicaciones con el componente geográfico asociado. El primer acercamiento para el caso colombiano somo se indicó previamente corresponde a GeoCOL en el 2011 y en la actualidad sumados a red de datos enlazados la información geográfica catastral del IGAC y la UAECD.



7. Conclusiones y Recomendaciones

Este capítulo se divide en tres secciones orientadas a mostrar la solución a la problemática

planteada en la formulación del presente proyecto de investigación. La primer sección

comprende los productos derivados de la investigación, la segunda las conclusiones del

desarrollo del proyecto y finalmente las recomendaciones o líneas para futuras

investigaciones.

7.1.1 Productos derivados de la Investigación

Los productos derivados de la investigación, se listan a continuación en correspondencia a los cuatro objetivos específicos planteados:

1. En la tabla 7-1, es posible observar un listado del resultado de la documentación de la caracterización del estado actual del tema a nivel internacional mediante el análisis de modelos internacionales, recopilación de información de vocabularios, tecnología disponible para su implementación e inventario de posibles conjuntos de datos a vincular de proyectos similares.

Tabla 7-1: Productos derivados de la investigación Objetivo Específico 1

Conclusiones 159

2. En la tabla 7-2 se observa los productos derivados de la caracterización de los modelos de datos catastrales del IGAC y del Catastro Descentralizado de Bogotá y sus sistemas y servicios para disposición de éstos en la web. Además la caracterización del modelo LADM encontrado en la etapa de análisis y diagnóstico de datos en el capítulo anterior. Finalmente como resultado del análisis de las tres fuentes de datos nombradas anteriormente, el modelado de LADM_CO, modelo LADM adaptado para los modelos catastrales geográfico colombiano.


3. El resultado del proceso de la integración de los modelos de datos catastrales Nacional y Distrital, a partir del desarrollo de las ontologías Catastral Nacional y Distrital, su homologación con LADM_CO y finalmente la construcción de la red de ontologías geográficas para la temática catastral.




4. En el proceso final se llevó a cabo la generación de los datos en formato RDF, la publicación y vinculación de un conjunto de datos geográficos catastrales conforme al modelo Nacional y Distrital establecidos bajo los parámetros del Linked Data Geográfico.


7.1.2 Conclusiones

La elaboración de este proyecto de investigación tiene un impacto positivo en el marco tecnologías aplicadas a la temática catastral teniendo en cuenta los siguientes aspectos:

1. La utilización de ontologías permite la integración de datos que siguen diferentes modelos de datos teniendo en cuenta el significado de estos. Por ejemplo tener una aplicación que permita la visualización, consulta y análisis de información de dos catastros con diferentes modelos (nombre, atributos, dominios). El usuario no tiene que ver las diferencias entre los datos y el análisis pasa de ser visual o manual a hacerse de manera automática con ayuda de aplicaciones informáticas.

2. Los datos publicados mediante la aplicación de estas tecnologías son reusables en

otros proyectos y es posible su integración con otras fuentes de datos. Por ejemplo podría ser divididas las responsabilidades en cuanto a publicación de información de catastro entre la información predial y la del propietario, estas podrían tener dos diferentes custodios pero estar totalmente integradas y disponibles en la web.

3. El desarrollo de redes de ontologías para la integración de los modelos de datos catastrales del IGAC y Catastro Bogotá homologados a un estándar internacional amplía el enfoque con respecto a la estandarización de los datos para facilitar el uso e intercambio de los mismos incluso en el contexto internacional.

Conclusiones 161

4. Publicar y vincular la información geográfica catastral con otros datos dispuestos en la web permite la interacción de los datos catastrales con otras disciplinas relacionadas de alguna manera con la administración geográfica de la tierra. Esta es una aproximación al denominado catastro multifinalitario.

5. La difusión de datos geográficos catastrales realizado a través del presente proyecto de investigación corresponde al primer caso a nivel mundial de publicación de información geográfica asociada a la temática catastral y el segundo caso a nivel nacional de Linked Data Geográfico, el primer caso corresponde a la tesis de maestría “Linked Data Geográfico conforme a geoSPARQL, caso de aplicación: División Territorial y Administrativa de Colombia”.

6. La aplicación de la herramienta st-silk y su extensión geotools permite aplicar análisis de relaciones espaciales a partir de la geometría de los datos en el contexto de la vinculación de datos.

7. La elaboración del proyecto de investigación genera un avance para el país en la

implementación de nuevas tecnologías al contexto geoespacial, considerando que en la actualidad ha sido poca la exploración e investigación de la web semántica en datos geográficos a nivel Nacional.

8. Los resultados de la implementación del presente proyecto de investigación brinda

a la entidad oficial que tiene en custodia el catastro nacional conocer nuevas herramientas para la toma de decisiones en cuanto a la implementación técnica de éstas nuevas tecnologías, evaluando las fortalezas adicionales en términos de publicación y difusión de la información catastral nacional.

9. Mejoría en la integración y publicación a partir de la aplicación de la web semántica,

aspecto que aún no ha sido incorporado en el catastro nacional.

7.1.3 Recomendaciones y líneas futuras de investigación

A partir de los resultados del presente proyecto de investigación se deja abierta la posibilidad para la exploración e investigación de algunos temas:

1. En base al proyecto piloto implementado que consta de la integración y publicación de datos geográficos catastrales del IGAC y catastro de Bogotá, implementar y reutilizar las ontologías producto de este proyecto de investigación para implementarlo con los demás catastros descentralizados (Cali, Medellín y Antioquía); de esta forma, estandarizar y establecer la infraestructura de datos espaciales catastrales a nivel nacional.

2. Realizar proyectos de integración y publicación con otras entidades gubernamentales de sector, social, ambiental y cultural que trabajen el detalle predial con el fin de generar un solo estándar a nivel nacional, permitiendo



potencializar el uso y aprovechamiento de la información apuntando al denominado catastro multifinalitario.

3. La Interrelación catastro registro es un tema en el cual no se ha avanzado mucho a nivel nacional, en realidad se han desarrollado hasta el momento algunas aplicaciones como el ICARE (Interrelación Catastro Registro) y el IPER (Interrelación Permanente), que si bien han ayudado a abordar las labores requeridas en esta temática, no han tenido el éxito esperado a la hora de evaluar resultados; por lo cual se plantea la aplicación de la web semántica en la interrelación catastro registro como una oportunidad de mejora e inversión tecnológica en los procesos emprendidos. En otros países han sido aplicados los lineamientos de la web semántica en la temática en cuestión encontrando valiosos resultados que valdría la pena analizar e investigar para el desarrollo del país.

Anexos 163

A. Anexo: Licencia de Uso – datos Geográficos Catastrales Municipio de Soacha

Anexos 165

B. Anexo: Análisis del modelo de datos catastral Nacional y Distrital respecto a LADM

El Anexo B corresponde al resultado del análisis del modelo de datos catastral Nacional y Distrital respecto al estándar internacional de administración de la tierra LADM:

Mapeo_ModeloDat

os_Nacional_Distrital_LADM.xlsx



C. Anexo: Catalogo de objetos modelo LADM_CO

Nombre: Catálogo de objetos de la información catastral publicada como datos vinculados del IGAC y la UAECD

Alcance: El presente Catalogo de objetos define la estructura y definiciones de la ontología tomada como vocabulario base para la publicación como datos vinculados de la información catastral del IGAC y la UAECD de los Municipios de Soacha y Bogotá.

Campo de aplicación: Catastro

Número de versión: 002

Fecha de la versión: 15 de Mayo de 2015

Productor / Revisó: Andrea Flórez / Jhonny Saavedra

Nombre CO_UrbanPerimeter (Perímetro Urbano)

Código 01

Geometría Polígono

Padre Spatial Unit::LA_SpatialUnitGroup Geosparql:Feature

Definición Áreas del territorio Distrital o Municipal destinadas a usos urbanos por el Plan de Ordenamiento Territorial, que cuenten con infraestructura vial y redes primarias de energía, acueducto y alcantarillado. Pueden pertenecer a esta categoría las zonas con procesos de urbanización incompletos, comprendidos en áreas consolidadas con edificación que se definan como áreas de mejoramiento integral; están delimitadas por perímetros y podrán incluir los centros poblados de los corregimientos. (catálogo de objetos del IGAC)

Atributos

NOMBRE DEFINICIÓN CÓDIGO TIPO DE

DATO

UNIDAD DE

MEDIDA

REFERENCIA DEL

DOMINIO

VALORES DE DOMINIO

sugID*

localID*

Identificador de la instancia. En este caso corresponde al Código Dane del Municipio al que hace referencia el perímetro.

0101 String 5 No No

nameSpace*

El identificador de la fuente

0102 String 5 No IGAC, UAECD

hierarchyLevel* (nivelJerarquico)

El nivel de jerarquía de una subdivisión o zonificación administrativa

0103 Integer No 1

Anexos 167

name(nombre)

Nombre del municipio al que pertenece el perímetro urbano

0104 String

hasGeometry (tieneGeometria)

Representación geométrica de la instancia. En este caso como polígono (1..*)

0105 geosparql:geometry

Relaciones

NOMBRE DEFINICIÓN CÓDIGO ROL RELACIÓN CARDINALIDAD

hasPart (formadoPor)

CO_UrbanPerimeter puede agregar 0 o más CO_CadastralSector (del subtipo (registerType) Urban)

R0101 contiene Agregación 0..*

belongsTo (perteneceA)

CO_UrbanPerimeter debe pertenecer a un Municipio

R0102 Pertenece a pertenencia 1-1

Nombre CO_CadastralSector (Sector Catastral)

Código 02


Padre Spatial Unit::LA_SpatialUnitGroup, Geosparql:Feature

Definición Es la porción de terreno, urbano, rural o mixto, conformado por barrios, veredas o manzanas respectivamente, y delimitado por accidentes geográficos naturales o culturales. Los objetos de este tipo del tipo Urbano y rural solo aplican para IGAC y los del tipo mixto solo para la UAECD.

Atributos


DATO

UNIDAD DE

MEDIDA

REFERENCIA DEL

DOMINIO

VALORES DE DOMINIO

sugID*

localID*

Identificador de la instancia. En este caso corresponde al Código Dane del Municipio al que hace referencia el perímetro.

0201 String 9 No No

nameSpace*



hierarchyLevel* (nivel Jerarquico)


0203 Integer No 1 (mixed or Rural), 2 (Urban)



registerType*(tipoDeRegistro)

Ubicación de la sectorización catastral.

0204 String rural,urban, mixed




Relaciones


isPartOf (formaParteDe)

CO_CadastralSector (del subtipo (registerType) Urban) debe hacer parte de un perímetro urbano

R0201 conforma Agregación *..1


CO_CadastralSector (del subtipo (registerType) rural) puede estar formado por 0 o más CO_Vereda

R0202 contiene Composición 0..*


CO_CadastralSector (del subtipo (registerType) mixed) puede estar formado por 0 o más CO_Block



CO_CadastralSector (del subtipo (registerType) urban) puede estar formado por 0 o más CO_Neighborhood


Touches (seToca)

CO_CadastralSector puede tocarse con 0 o muchos CO_CadastralSector

R0702 seTocaCon adyacencia 1..0:*

Reglas

CO_CadastralSector de registerType Urban y rural solo aplican para información del IGAC y mixed solo para datos de la UAECD

Nombre CO_Neighborhood

(Barrio)

Código

04



Definición Espacio geográfico en que se divide el área urbana, donde se ubican un conjunto de manzanas (Catálogo de objetos del IGAC)

Anexos 169

Atributos


DATO

UNIDAD DE

MEDIDA

REFERENCIA DEL

DOMINIO

VALORES DE DOMINIO

sugID*

localID*

Identificador de la instancia

0401 String 13 No No

nameSpace*



hierarchyLevel*(nivelJerarquico)


0403 Integer No 3

name (nombre)

Nombre por el cual es conocido el Barrio

0404 String




Relaciones



CO_Neighborhood puede hacer parte de CO_CadastralSector (urban). Solo en caso de que provenga del IGAC.

R0401 conforma Composición *..0:1


CO_Neighborhood debe estar formado por 1 o más CO_Block


Touches (seToca)

CO_Neighborhood puede tocarse con 0 o muchos CO_Neighborhood


Nombre CO_Vereda Código 05



Definición Espacio geográfico en que se divide el área rural, donde se ubican un conjunto de predios (Catálogo de objetos del IGAC)

Atributos


DATO

UNIDAD DE

MEDIDA

REFERENCIA DEL

DOMINIO

VALORES DE DOMINIO



sugID*

localID*



nameSpace*



hierarchyLevel*


0503 Integer No 2

name (nombre)

Nombre por el cual es conocida la vereda

0504 String




Relaciones



CO_Vereda puede hacer parte de CO_CadastralSector (rural). Solo en caso de que provenga del IGAC.



CO_vereda debe estar formado por 1 o más CO_Land


Touches (seToca)

CO_vereda puede tocarse con 0 o muchos CO_vereda


Nombre CO_Block (Manzana) Código 03



Definición Espacio geográfico donde se agrupa un conjunto de lotes con o sin construcción los cuales se encuentran delimitados por espacio público y/o accidentes naturales. (catálogo de objetos mapa de referencia de Bogotá)

Atributos


DATO

UNIDAD DE

MEDIDA

REFERENCIA DEL

DOMINIO

VALORES DE DOMINIO

sugID*

localID*



Anexos 171

nameSpace*



hierarchyLevel*(nivelJerarquico)


0303 Integer No 4 urban, 2 mixed




Relaciones



CO_ Block debe hacer parte de CO_ Neighborhood.

R0301 conforma Composición *..1


CO_ Block debe estar formado por 1 o más CO_Land


Nombre CO_Land (Terreno) Código 06

Padre Spatial Unit::LA_SpatialUnit, Geosparql:Feature


Definición Mínima unidad geográfica donde se ubica uno o más construcciones y/o Unidades constructivas ya sean en el área urbana o rural (consensuada)

Atributos


DATO

UNIDAD DE

MEDIDA

REFERENCIA DEL

DOMINIO

VALORES DE DOMINIO

suID*

localID*



nameSpace*



area

areSize

Área del terreno 0603 Long

type (LA_AreaType)

Tipo de área 0604 String

calculatedArea, nonOfficalArea,officialArea, surveyedArea

localID

0605 CO_Address



extAddressID

Vinculo a la dirección de la Unidad espacial (0..*). Completa.

nameSpace*



Label (etiqueta)

Identificador textual por el cual es conocido el terreno

0606 String

referencePoint

Coordenadas de un punto dentro del terreno

0608 GM_Point (ISO 19107)




Relaciones



CO_Land puede hacer parte de CO_Vereda.



CO_Land puede hacer parte de CO_ Neighborhood.


contains (contiene)

CO_Land puede contener 0 o más CO_Building

R0603 contenedor centenecia 0..*

Touches (seToca)

CO_Land puede tocarse con 0 o muchos CO_Land


address (tieneDireccion)

CO_Land debe tener una o mas CO_Address (solo conexión con la(s) placas)

R0605 tieneDirección Ubicación 1..*:1

conectedLand

CO_Land puede estar conectado con otros CO_Land “dispersos”

R0607 conectadoCon conexion 1..0:*

Reglas

CO_Land debe hacer parte o de una CO_Vereda o de un CO_ Neighborhood. conectedLand en este momento solo puede ser calculada para la información de catastro distrital.

Nombre CO_Building (Construcción)

Código 07

Anexos 173

Padre Spatial Unit::LA_SpatialUnit, Geosparql:Feature


Definición Reunión de Materiales consolidada de carácter permanente destinada a proteger contra la intemperie a personas, animales o bienes. (Catálogo de objetos IGAC)

Atributos


DATO

UNIDAD DE

MEDIDA

REFERENCIA DEL

DOMINIO

VALORES DE DOMINIO

suID*

LocalID*



NameSpace*



Label (etiqueta)

Es el nombre común dado a la construcción.

0706 String 50

referencePoint

Coordenadas de un punto dentro de la construcción

0608 GM_Point (ISO 19107)

surfaceRelation

Indica la ubicación de la construcción respecto a la superficie

Above, below, mixed, on Su rface

numberOf Floors

Para cada polígono de construcción se tomará el número de pisos máximo que contenga.

0703 Integer

tieneSemisotano*

Indica si la construcción posee o no semisótano.

0704 Integer 1 No 0 - no tiene; 1 - tiene

tieneSotano* Numero de sótanos de la construcción.

0705 Integer




Relaciones


Within (estaContenida)

CO_Building debe estar contendia en 1 CO_Land

R0701 contenido contenencia *..1

Touches (seToca)

CO_Building puede tocarse con 0 o muchos CO_Building




Nombre CO_Address

(Nomenclatura Domiciliaria)

Código 08

Padre Geosparql:Feature

Geometría Point

Definición Placa de referencia con la ubicación de las entradas a un predio. (Catálogo de objetos mapa de referencia de Bogotá)

Atributos

NOMBRE DEFINICIÓN CÓDIGO

TIPO DE

DATO

UNIDAD DE

MEDIDA

REFERENCIA

DEL DOMINI

O

VALORES DE DOMINIO

LocalID* Identificador de la instancia 0801 String 30 No No

Placa*

Corresponde al texto que contiene el equivalente alfanumérico del eje generador de nomenclatura domiciliaria y la distancia aproximada en metros medida a partir de ese eje, ajustado al número decimal par o impar, así como el cuadrante Sur o Este según el caso. Para la identificación de los edificios, interiores, casas, bodegas, puede contener el texto que los diferencie, junto con el correspondiente número.

0803 String

Generadora Nombre o Numero de la Vía sobre la cual está ubicada la dirección

0804 String

Type

Este subtipo obedece a la categorización de la placa domiciliaria de acuerdo al tipo de placa dentro del lote.

0805 Integer No

1. Principal: Es la

nomenclatura domiciliaria asignada al acceso principal de un predio de acuerdo a las características físicas observadas en terreno.

2. Secundaria: Es la

nomenclatura domiciliaria asignada a los accesos localizados sobre la misma vía de la nomenclatura principal.

3. Incluye: Es la

nomenclatura domiciliaria asignada a los accesos que se localizan sobre vía

Anexos 175

diferente a la de la nomenclatura principal.

4. Adicional PH: Es la

nomenclatura adicional sobre propiedad horizontal representada cartográficamente y que no posee representación alfanumérica en la UAECD. Ej.: nomenclatura de accesos a garajes en PH.

5. Provisional DSU: Es

la nomenclatura asignada provisionalmente a futuros Desarrollos Urbanísticos. Esta nomenclatura será definitiva cuando se desarrolle el proyecto.




Relaciones

NOMBRE DEFINICIÓN CÓDIGO

ROL RELAC

IÓN CARDINALIDAD

addressFrom

una o más CO_Address referencia(n) un CO_Land

R0801

Referencia Ubicación

Nombre CO_LegalSpaceBuildingUnit

Código 09

Padre Spatial Unit:: LA_LegalSpaceBuildingUnit, Geosparql:Feature


Definición Espacio geográfico en que se divide el área rural, donde se ubican un conjunto de predios (Catálogo de objetos del IGAC)

Atributos


DATO

UNIDAD DE

MEDIDA

REFERENCIA DEL

DOMINIO

VALORES DE DOMINIO

sugID*

localID*



nameSpace*





Label (etiqueta)

Es el nombre común dado a la construcción.

0903 String 50

area

areSize

Área del terreno 0904 Long

type (LA_AreaType)

Tipo de área 0905 String

calculatedArea, nonOfficalArea,officialArea, surveyedArea

surfaceRelation

Indica la ubicación de la construcción respecto a la superficie

0910 Above, below, mixed, on Su rface




Relaciones



CO_LegalSpaceBuildingUnit debe hacer parte de CO_Building.

R0901 conforma Composición *:1..1

Reglas

CO_ LegalSpaceBuildingUnit solo aplica para información proveniente del IGAC.

Anexos 177

D. Anexo: Especificación de requerimientos de la ontología

Especificación de requerimientos de Ontologías

1 Propósito

Tener un vocabulario base para la generación de datos catastrales como Linked Data, que conserve la información de geometría y relaciones espaciales.

2 Alcance

La ontología se basara en el estándar ISO 19152 – LADM y se extenderá al dominio de la información geográfica catastral generada por la Subdirección de Catastro del IGAC y la Unidad Administrativa Especial de Catastro Distrital de la ciudad de Bogotá. Solo se tendrán en cuenta los tipos de objetos relacionados con el aspecto físico del catastro.

3 Nivel de formalidad

La ontología será implementada en formato OWL

4 Usuarios

USUARIO 1. Productores de Linked Data geográfico en Colombia para estructurar y documentar su información.

USUARIO 2. Entidades y personas que requieran el uso de la información catastral de manera unificada. A nivel público principalmente entidades de carácter nacional que utilizan la información catastral como insumo básico para la toma de decisiones como los ministerios, presidencia, planeación, DANE, IDEAM, etc.

USUARIO 3. Entidades productoras y gestoras de la información catastral: El Instituto Geográfico Agustín Codazzi y los catastros descentralizados.

USUARIO 4. Cualquier otro usuario que pueda reutilizar la información geográfica catastral para elaborar otras ontologías o aplicaciones relacionadas.

5 Usos

USO 1. Generación de Linked Data geográfico de la información geográfica catastral producida por el IGAC y la UAECD.

USO 2. Podrá ser utilizada como ontología del dominio de información geográfica catastral.

USO 3. Integración de datos geográficos catastrales del IGAC y la UAECD.

USO 4. Vinculación e integración de datos catastrales con otros tipos de datos.

6 Requerimientos de la ontología



6.1 Requerimientos no funcionales

RNF1. La ontología debe soportar sus uso en Español e Ingles

RNF2. Hasta donde sea posible de debe reaprovechar lo estándares internacionales existentes.

RNF3. Para el proyecto piloto solo se tendrá en cuenta los aspectos físicos del catastro.

RDF4. Solo se considerarán los datos que son susceptibles de publicación; es decir los que no se encuentran cubiertos por ley de habeas data.

6.2 Requerimientos funcionales

Preguntas de competencia (CQ)

Preguntas de consulta básica por identificador:

1. ¿Cuál es la Construcción (Unidad, Lote, Manzana etc.) identificada con determinado código catastral?

Preguntas de consulta por dirección

1. ¿Cuál es la construcción (Unidad, Lote) ubicada en determinada dirección? 2. ¿Cuántas placas esta asociadas a determinado Lote?

Preguntas de relaciones espaciales

1. ¿Cuáles lotes (construcciones, unidades, etc.) se encuentran contenidos en determinada manzana (Barrio, Sector Catastral, Municipio, Localidad etc.)?

2. ¿Cuáles son los lotes (construcciones, manzanas) que colindan con determinado Lote (Construcción, Manzana etc.)?

3. ¿Cuáles elementos se encuentran en el box (Xmáx, Ymáx, Xmin, Ymin)?

Preguntas de número:

1. ¿Cuántas Construcciones tiene determinado Municipio (Lote, Manzana, Sector, etc.)? 2. ¿Cuál sector tiene mayor cantidad de predios el urbano o el rural? 3. ¿Cuántas unidades en PH tiene determinada Construcción?

Preguntas de área

1. ¿Cuánto es el área del Lote (Unidad, Construcción)?

7 Pre-Glosario de términos

Conceptos:

Municipio

Localidad

Sector

Barrio

Manzana

Lote

Construcción

Anexos 179

Unidad Atributos:

Placa

Dirección

Área

Numero

Código Catastral Relaciones:

Colindan

Contenido Otros aspectos a tener en cuenta:

Geometría

Relaciones espaciales

Sistema de referencia

8 Esquema de red de ontologías preliminar

GeoSPARQL GeoCol

LADM_CO



E. Anexo: Especificación de Requerimientos de los datos

DESCRIPCIÓN DE LA ESPECIFICACIÓN

Parámetros Generales

1.1.1 Estándar NTC 5662

1.1.2 Restricciones Ninguna

Control de Cambios

1.2.1 Versión 1.2.2 Numeral 1.2.3 Descripción 1.2.4 Fecha 1.2.5 Responsable

1 0 Elaboración de la

especificación 16/09/2013 Jhonny Saavedra

Visión general

1.3.1 Términos y definiciones

Ontología: “El concepto de ontología nace de la filosofía y se refiere a “explicación sistemática del ser”. La web

semántica rescata la noción de ontología del campo de la filosofía, y la trae al contexto de la ingeniería del conocimiento para hacer una explicación sistemática de los recursos que componen la web. Una ontología según Gruber es “una especificación formal explícita de una conceptualización compartida” [Gruber 1993]

Linked Data (Datos vinculados): Con el Linked Data la web semántica usa la web para conectar datos relacionados que no han sido vinculados previamente. Busca compartir datos estructurados en la red tan fácilmente como hoy se pueden compartir documentos. El supuesto básico detrás de los datos vinculados es que el valor y la utilidad de los datos aumentan en cuanto está más interrelacionada con otros datos.

Web Semántica: Es una extensión de la red de datos actual dando a la información un significado bien definido, para facilitar a las computadoras y personas trabajar conjuntamente. Se basa en la idea de tener los datos definidos en la web y vinculados de manera que puedan ser utilizados para el descubrimiento más eficaz, la automatización, integración y reutilización a través de aplicaciones (Hendler et al., 2002).

Catastro: Inventario o censo, debidamente actualizado y clasificado, de los bienes inmuebles pertenecientes al Estado y a los particulares, con el objeto de lograr su correcta identificación de los elementos físico, jurídico, económico y fiscal. 65

1.3.2 Abreviaturas

IGAC – Instituto Geográfico Agustín Codazzi

CIAF – Centro de Investigación y Desarrollo en Información Geográfica

UACD - Unidad Administrativa Especial de Catastro Distrital

RDF - Resource Description Framework -

OWL - Web Ontology Language

LADM – “Land Administration data Model”

Alcance

65 IGAC. Resolución No. 70 de 2011.

Anexos 181

1.4.1 Identificación del alcance

Se publicaran datos catastrales provenientes de la subdirección de catastro del IGAC y de la UAECD siguiendo lineamientos de la web semántica

1.4.2 Nivel jerárquico Subconjunto de datos

1.4.3 Extensión Sector Catastral del Distrito Capital y un sector catastral del Municipio de Soacha (Cundinamarca) limitantes

1.4.4 Cobertura Componente físico del catastro. Específicamente los tipos de objetos relacionados con el predio y sus agrupaciones hasta el nivel de municipio. La nomenclatura vial y los usos de estos

IDENTIFICACIÓN DEL CONJUNTO DE DATOS

Identificación del Producto

2.1.1 Título Datos catastrales abiertos y vinculados de la ciudad de Bogotá y el municipio de Soacha

2.1.2 Título alterno Open Linked Data Catastral de Bogotá y Soacha

2.1.3 Resumen Integración y publicación de datos básicos de catastro de la ciudad de Bogotá y el municipio de Soacha como datos abiertos y vinculados; utilizando como vocabulario base un perfil del modelo internacional de catastro LADM

2.1.4 Propósito

Disponer de manera abierta, con un mismo vocabulario y en un formato que permita los análisis semánticos y la vinculación con otros datos. La información catastral referente al aspecto físico del catastro de la subdirección del IGAC y la UAECD. Con esto se quiere probar la aplicabilidad de la Web semántica en este tipo de datos y tener un primer acercamiento a su uso en el contexto de las Infraestructuras de Datos Espaciales

2.1.5 Categoría temática Planeación/Catastro

2.1.6 Descripción geográfica

Áreas Urbanas y Rurales del Municipio de Soacha y la Ciudad de Bogotá

2.1.7 Coordenadas geográficas límites

-74.4519, 3.7281 ; -73.9959, 4.8390

2.1.8 Tipo de representación espacial

Vector

2.1.9 Resolución espacial

A nivel urbano Escala 1:500, en áreas rurales Escala 1:25.000 y 1:10.000

2.1.10 Información adicional

Para ver información adicional remítase a los capítulos 3 y 4 de diagnóstico y modelamiento de datos

Contenido y estructura de los datos

Vector



3.1.1.1 Esquema de aplicación

UML modelo conceptual de la Ontología.

3.1.1.2 Catálogo de objetos

Catálogo de Objetos

SISTEMAS DE REFERENCIA

Sistema de referencia espacial

Coordenadas Geográficas

4.1.1.1. Código 4686

4.1.1.2 Responsable del identificador del sistema

EPSG

4.1.2 Dátum horizontal

NOMBRE DEL DÁTUM HORIZONTAL: MAGNA - SIRGAS Nombre del elipsoide: GRS 80 Semi-eje mayor: 6 378 137 Relación de achatamiento: 1/298,257222101 Nombre del Dátum de altitud: Buenaventura Resolución y unidades de distancia de altitudes: 0.001 metros Factor de escala: 1 Falso Este: 1'000,000 Falso Norte: 1'000,001 Coordenadas geográficas límites Oeste: -79.06 Este: -66.91 Norte: 12.65 Sur: -4.22

CALIDAD DE LOS DATOS

Control de Calidad: No se harán controles de calidad a los datos. Se referencia a la calidad de las fuentes.

Declaración de Captura de datos

5.2.1 Fuentes de información

Subdirección de Catastro IGAC: Datos catastrales del municipio de Soacha estructurados según modelo del SNC.

UAECD: Datos dispuestos en el Catálogo de datos del Mapa de Referencia de Bogotá66.

ENTREGA DEL CONJUNTO DE DATOS

Forma de entrega

66http://www.ideca.gov.co/index.php?q=es/content/cat%C3%A1logo-de-datos-geogr%C3%A1ficos-mapa-de-referencia

Anexos 183

6.1.1 Formato RDF

6.1.3 Estructura del archivo

Ver: UML con modelo conceptual de la Ontología (Capítulo 4, Ítem 4.6)

Ver: Patrón de URIs (Capítulo 5, Ítem 5.1.4)

6.1.5 Idioma Vocabulario Inglés y español. Contenido Español.

Medio de entrega

6.2.1 Unidades de entrega

Conjunto de datos de un tipo de objeto determinado o los datos de una instancia.

6.2.2 Nombre del medio En línea

Bibliografía 185

Bibliografía

[1] ALCALDÍA MAYOR DE BOGOTÁ. Normas Catastrales. Editora Guadalupe Ltda. Santa Fe de Bogotá D.C. 1999.

[2] ALONSO PEÑA, Carlos. FERNÁNDEZ GÓMEZ, Roberto y YAÑEZ MORANTE, Elsa. Consulta y actualización de información catastral mediante servicios web”. Tecnimap. Página web tecnimap. 2007.

[3] ANTADA ZARZOSA, Nieves. Sistemas de Información Geográfica. Universidad Politécnica de Cataluña. Barcelona. 2004.

[4] BATTLE, R. KOLAS, D. Enabling the Geospatial Semantic Web with Parliament and GeoSPARQL, 0(0), 1–17.

[5] BIZER, C. CYGANIAK, R. HEATH, T. How to publish linked data on the web. http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/. 2007.

[6] DÁVILA, N. Ontología web semántica del registro catastral venezolano Semantic web ontology of venezuelan official land registry. 2010.

[7] DAVILA, J. Agents in Logic Programming. Tesis Doctoral. Imperial College. 1997.

[8] DÍAZ, L. GRANELL, C. GOULD, M. Spatial Data Integration over the Web. Ferraggine, V. EMMONS, Ian. Parliament TM, Marzo 24 2014.

[9] EGENHOFER, M. FONSERCA, F. AGOURIS, P. Using ontologies for integrated geographic information systems. 2002.

[10] EGENHOFER, M. FONSERCA, F. AGOURIS, P. Using ontologies for integrated geographic information systems. 2002.

[11] ERBA, Diego Alfonso. Catastro Multifinalitario aplicado a la definición de políticas de suelo urbano. Cambridge. MA: Lincoln Institute Of LandPolicy. 2007.

[12] FRAMEWORK, C. ZAVERI, A. RULA, A. MAURINO, A. PIETROBON, R. LEHMANN, J. Quality Assessment Methodologies for Linked Open Data, 1, 1–5. 2012.

http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/

186 Integración y publicación como “Open Linked Data” de información geográfica catastral

a través de redes de ontologías bajo el contexto de la web semántica

[13] FONSECA, Joao Paulo. Development Methodology for an Integrated Legal Cadastre. Juli 2012.

[14] GÓMEZ, Jorge Hernando. Sistemas de Información Geográfica. Universidad Industrial de Santander. Bucaramanga. 2005.

[15] Geographic Information Land Administration Domain Model (LADM). ISO/DIS 19152. October 2010.

[16] HARTH, Andreas. Semantic Web Architecture. 2010.

[17] HEATH, T. HAUSENBLAS, M. BIZER, C. CYGANIAK, R. HARTIG, O. How to Publish Linked Data on the Web. October 2008.

[18] Heitmann, B. Kinsella, S. Hayes, C and Decker, S. Implementing semantic web applications: reference architecture and challenges. In Proceedings of 5th International Workshop on Semantic Web Enabled Software Engineering, co-located with ISWC 2009, 2010

[19] HENDLER, J. MILLER, E. BERNERS, L. Integrating applications on the semantic web. 2002.

[20] INSTITUTO GEOGRÁFICO AGUSTÍN CODAZZI, CIAF. Catálogo de Objetos Geográficos del IGAC. 2005.

[21] JANOWICZ, K. SCHEIDER, S. PEHLE, T. HART, G. Geospatial Semantics and Linked Spatiotemporal Data – Past, Present, and Future, 0, 1–13. 2012.

[22] KAUFMANN, Jurg y STEUDLER, Daniel. Catastro 2014: Una visión para un sistema catastral futuro – Grupo de Trabajo 1 de la Comisión 7 de la FIG (Federación Internacional de Agrimensores). 1998.

[23] Knowledge Web Consortium. Specification of a common framework for characterizing alignment. Deliverable 2.2.1. KWEB/2004/D2.2.1/v2.0. Disponible en: http://www.inrialpes.fr/exmo/cooperation/kweb/heterogeneity/deli/kweb-221.pdf. 2005.

[24] LAURINI, R. Workshop on Urban Ontologies. INSA. Lyon. P.10. 2004. Disponible en: http://liris.cnrs.fr/robert.laurini/resact/urban-ontologies.pdf

[25] LEBEAU, Jean Roch. Cartografía Catastral: Un concepto todavía de actualidad?. Lincoln Institute Of LandPolicy.

[26] Ley 388 del 18 de julio de 1997. Ley de Ordenamiento Territorial.

[27] LI, M. ZHU, X. SHEN, C. CHEN, D. GUO, W. The development of cadastral domain model oriented at unified real estate registration of china based on ontology, September 2012.

http://www.inrialpes.fr/exmo/cooperation/kweb/heterogeneity/deli/kweb-221.pdf

http://liris.cnrs.fr/robert.laurini/resact/urban-ontologies.pdf

Bibliografía 187

[28] LOZADA, Pablo. Evolución de la web.

[29] NARANJO, A. Sistemas de Información Geográfica. Departamento de Geografía. 2001.

[30] OOSTEROM, Van. LEMMEN, C. The Core Cadastral Domain Model : A Tool for the Development of Distributed and Interoperable Cadastral Systems. 1996.

[31] PIATTINI. Arquitectura de gestión de conocimiento. 2007.

[32] PIÑA N. Ontología espacio temporal de Registro Catastral venezolano como base para la creación de Sistemas de Información Territorial. ULA. Tesis para optar al grado de Magister Scientiae. 2006.

[33] POVEDA VILLALÓN, María. Red de Ontologías para el camino de Santiago. Trabajo fin de carrera. Universidad Politécnica d Madrid. Marzo 2009.

[34] POULIOT, J. VASSEUR, M. Spatial Representation of Condominium / Co-ownership : Comparison of Quebec and French Cadastral System based on LADM Specifications. November 2011.

[35] Resolución 70. Por la cual se reglamenta técnicamente la formación catastral, la actualización de la formación catastral y la conservación catastral. 2011.

[36] SAAVEDRA, J. VILCHES-BLÁZQUEZ, L. M. BOADA, A. Cadastral data integration through Linked Data Colombian Cadastre : An integration use Cadastral data integration, (Iso 19152), 3–6. 2014.

[37] SAAVEDRA VELÁZQUEZ, Jhonny Alexis. Linked Data Geográfico conforme a geosparql – caso de aplicación División Territorial y Administrativa de Colombia. Tesis de Maestría. Universidad Politécnica d Madrid. 2011.

[38] SMITS, P. (Ed.) INSPIRE Architecture and Standards Position Paper.Architecture and Standards Working Group. Document available at http://inspire.jrc.it/documents/inspire_ast_pp_v4_3_en.pdf. 2002.

[39] SUAREZ, María del Carmen. NeOn Methodology for Building Ontology Networks : Specification, Scheduling and Reuse. Tesis de Doctorado. Universidad Politécnica d Madrid. June 2010.

[40] UITERMARK, H. OOSTEROM, Van. Zevenbergen, J. Lemmen, C. From LADM / STDM to a Spatially Enabled Society : a Vision for 2025. April 2010.

[41] UNIDAD ADMINISTRATIVA ESPECIAL DE CATASTRO DISTRITAL, IDECA. Catálogo de Objetos Geográficos del Mapa de Referencia para el Distrito Capital. 2006.

http://inspire.jrc.it/documents/inspire_ast_pp_v4_3_en.pdf



[42] VÍLCHEZ BLÁZQUEZ, Luis Manuel. RAMOS GARGANTILLA, José Ángel. Conflación semántica: un estudio sobre la integración de información geoespacial basada en ontologías. International Review of Geographic Information Science and Technology. 2012.

[43] VÍLCHEZ BLÁZQUEZ, Luis Manuel. Metodología para la integración basada en ontologías de información de bases de datos heterogéneas en el dominio geográfico. Tesis de Doctorado. Universidad Politécnica de Madrid. 2011.

[44] VILCHES-BLÁZQUEZ, L. M. VILLAZÓN-TERRAZAS, B. LEON, A. PRIYATNA, F. CORCHO, O. (n.d.). An Approach to Publish Spatial Data on the Web : The GeoLinked Data Case.

[45] WERNER, Kuhn. Ontologies in support of activities in geographical space. International Journal of Geographical Information Sciencie. 2010.

[46] http://landregistry.data.gov.uk/

[47]http://www.igac.gov.co/wps/portal/igac/raiz/iniciohome/nuestraentidad/!ut/p/c5/04_SB8K8xLLM9MSSzPy8xBz9CP0os3hHT3d_JydDRwN3t0BXA0_vUKMwf28PIwNHI30v_aj0nPwkoMpwkF7caj1NIfIGOICjgb6fR35uqn5BdnCQhaOiIgDx-NPO/dl3/d3/L3dDb0EvUU5RTGtBISEvWUZSdndBISEvNl9BSUdPQkIxQTBHRlFFMElLVTJWT0tIMjBBNw!!/

[48]http://www.ideca.gov.co/index.php?q=es/content/misi%C3%B3n-y-objetivos-estrat%C3%A9gicos

[49] http://linkedgeodata.org

[50] http://geo.linkeddata.es

[51] http://www.ordnancesurvey.co.uk/oswebsite/products/os-opendata.html

[52]http://www.maestrosdelweb.com/editorial/web-semantica-y-sus-principales-caracteristicas/

[53]http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/methodologies/59-neon-methodology

[54] https://es.wikipedia.org/wiki/Web_sem%C%A1ntica

[55] http://www.icde.org.co/web/guest/estandares_catalogo

[56] http://www.digitaldivide.net/articles/view.php?ArticleID=20

[57] https://alexis1703.wordpress.com/componentes-de-la-web-3-0/

http://www.igac.gov.co/wps/portal/igac/raiz/iniciohome/nuestraentidad/!ut/p/c5/04_SB8K8xLLM9MSSzPy8xBz9CP0os3hHT3d_JydDRwN3t0BXA0_vUKMwf28PIwNHI30v_aj0nPwkoMpwkF7caj1NIfIGOICjgb6fR35uqn5BdnCQhaOiIgDx-NPO/dl3/d3/L3dDb0EvUU5RTGtBISEvWUZSdndBISEvNl9BSUdPQkIxQTBHRlFFMElLVTJWT0tIMjBBNw!!/







http://linkedgeodata.org/

http://geo.linkeddata.es/

http://www.ordnancesurvey.co.uk/oswebsite/products/os-opendata.html

http://www.maestrosdelweb.com/editorial/web-semantica-y-sus-principales-caracteristicas/

http://www.maestrosdelweb.com/editorial/web-semantica-y-sus-principales-caracteristicas/

http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/methodologies/59-neon-methodology

http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/methodologies/59-neon-methodology

https://es.wikipedia.org/wiki/Web_sem%25C%A1ntica

https://alexis1703.wordpress.com/componentes-de-la-web-3-0/

Bibliografía 189

[58] W3C. What is Linked Data?. { http://www.w3.org/standards/semanticweb/data

[59] http://www.w3.org/TR/rdf-schema/

[60] http://www.w3.org/TR/owl-features/

[61] http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/technologies/57-nor2o

[62] http://mapas.bogota.gov.co/geoportal/

[63]http://mapas.catastrobogota.gov.co/arcgiswsh/Mapa_Referencia/Mapa_referencia/MapServer/WMSServer?

[64] http://www-306.ibm.com/software/awdtools/rup/

[65] http://en.wikipedia.org/wiki/Semantic_Web_Stack

[66] http://en.wikipedia.org/wiki/Resource_Description_Framework

[67]http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=51206

[68] http://www.w3.org/2003/01/geo/

[69] http://www.opengeospatial.org/standards/geosparql

[70] http://www.geonames.org/ontology/documentation.html

[71] www.dbpedia.org

[72] http://protege.stanford.edu/

[73] http://virtuoso.openlinksw.com/

[74]http://www.oracle.com/technetwork/database-options/spatialandgraph/overview/rdfsemantic-graph-1902016.html

[75] http://www.ontotext.com/owlim

[76] https://opensahara.com/en?destination=home

[77] http://www.strabon.di.uoa.gr/

[78] http://d2rq.org/

[79] https://metacpan.org/release/RDF-RDB2RDF

http://www.w3.org/standards/semanticweb/data

http://www.w3.org/TR/owl-features/

http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/technologies/57-nor2o

http://mapas.catastrobogota.gov.co/arcgiswsh/Mapa_Referencia/Mapa_referencia/MapServer/WMSServer

http://mapas.catastrobogota.gov.co/arcgiswsh/Mapa_Referencia/Mapa_referencia/MapServer/WMSServer

http://www-306.ibm.com/software/awdtools/rup/

http://en.wikipedia.org/wiki/Semantic_Web_Stack

http://en.wikipedia.org/wiki/Resource_Description_Framework



http://www.w3.org/2003/01/geo/


http://www.dbpedia.org/

http://protege.stanford.edu/

http://virtuoso.openlinksw.com/

http://www.oracle.com/technetwork/database-options/spatialandgraph/overview/rdfsemantic-graph-1902016.html

http://www.oracle.com/technetwork/database-options/spatialandgraph/overview/rdfsemantic-graph-1902016.html

http://www.ontotext.com/owlim

https://opensahara.com/en?destination=home

http://www.strabon.di.uoa.gr/

http://d2rq.org/

https://metacpan.org/release/RDF-RDB2RDF



[80] http://capsenta.com/ultrawrap

[81] http://wifo5-03.informatik.uni-mannheim.de/bizer/silk/

[82] https://github.com/psmeros/stSilk

[83] http://aksw.org/Projects/LIMES.html

[84] http://aws.amazon.com/es/ec2/

[85] https://github.com/jasaavedra/shp2geosparql

[86] https://github.com/psmeros/stSilk

[87] http://srvmetadata.igac.gov.co/swami/app/#

http://capsenta.com/ultrawrap

http://wifo5-03.informatik.uni-mannheim.de/bizer/silk/

http://aksw.org/Projects/LIMES.html

http://aws.amazon.com/es/ec2/

https://github.com/jasaavedra/shp2geosparql

https://github.com/psmeros/stSilk


INTEGRACIÓN Y PUBLICACIÓN COMO “OPEN LINKED DATA” DE...

Documents

Transcript of INTEGRACIÓN Y PUBLICACIÓN COMO “OPEN LINKED DATA” DE...