Autor: javiermurcia

  • Transformando el Patrimonio de Murcia: De XML estático a Web Semántica Inteligente

    Gran parte de los datos culturales publicados por administraciones públicas se distribuyen en formatos cerrados o semi-estructurados, difíciles de integrar, reutilizar o cruzar con otras fuentes.

    Este proyecto aborda ese problema mediante técnicas de Web Semántica, transformando datos institucionales en un grafo de conocimiento interoperable.

    Objetivos del proyecto

    El objetivo no era solo publicar una web, sino demostrar un flujo completo de transformación, modelado, enriquecimiento semántico y explotación de datos culturales.

    Es decir la conversión de datos a rdf y su normalización con una ontología owl, que permita integrar esos datos a otras fuentes y grafos.


    Transformar descripciones estáticas en un grafo de conocimiento navegable al tiempo que convertimos datos aislados y sin contexto temporal ni relacional en LOD.

    Transformación y normalización de datos


    Partimos de la conversión del archivo Lugares de interés de la Región de Murcia. Puesto a disposición por la Comunidad Autónoma de la Región de Murcia, y que contiene información sobre lugares destacados por su interés turístico y cultural.

    Comenzando con el archivo en formato XML, lo transformé a formato CSV con objeto de utilizar la librería Tarql, que es una herramienta de línea de comandos que convierte archivos CSV a RDF utilizando la sintaxis SPARQL 1.1.

    Tarql nos permite mapear cada campo del archivo CSV a las clases y propiedades previamente elaboradas en una ontología, así como asignar el tipo de dato adecuado. Como por ejemplo, coordenadas espaciales o fechas.


    Script de Tarql:

    PREFIX monu: <http://www.monumentos.es/>
    PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
    PREFIX lugares: <http://www.monumentos.es/lugares/>
    PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
    PREFIX owl:   <http://www.w3.org/2002/07/owl#>
    PREFIX  geo:   <http://www.w3.org/2003/01/geo/wgs84_pos#>
    PREFIX geosparql: <http://www.opengis.net/ont/geosparql#>
    PREFIX  rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
    CONSTRUCT {
      ?URI a monu:Sitio_de_interés;
        rdf:type ?Tipo_;
        rdf:type ?Subtipo_;
        rdfs:label ?Nombre_;
        rdfs:comment ?Descripción_;
        monu:Está_en_Provincia lugares:Provincia_de_Murcia;
        monu:Está_en_Municipio ?Municipio_;
        monu:Está_en_localidad ?Pedanía;
        monu:CP ?CP_;
        monu:Dirección ?Dirección_;
        monu:TLF ?Teléfono_;
        monu:FAX ?FAX_;
        monu:Email ?Email_;
        monu:Web ?URL_Real;
        monu:Web ?URL_Corta;
        geo:lat ?lat_;
        geo:lon ?lon_;
        monu:Imagen1 ?Foto_1;    
    }
    FROM <file:/-/Monumentos-Región-de-Murcia-comas.csv>
    WHERE {
      BIND (URI(CONCAT('http://www.monumentos.es/', ENCODE_FOR_URI(?Nombre))) AS ?URI)
      BIND (IRI(CONCAT('http://www.monumentos.es/lugares/', ENCODE_FOR_URI(?Municipio))) AS ?Municipio_)
      BIND (URI(CONCAT('monu:', ENCODE_FOR_URI(?Subtipo))) AS ?Subtipo_)
      BIND (URI(CONCAT('http://www.monumentos.es/', ENCODE_FOR_URI(?Tipo))) AS ?Tipo_)
      BIND (STRLANG(?dirección, "es") as ?Dirección_)
      BIND (xsd:string(?FAX) AS ?Fax)
      BIND (STRDT(?Teléfono,xsd:string) as ?Teléfono_)
      BIND (STRDT(?Email,xsd:string) as ?Email_)
      BIND (STRDT(?CodigoPostal,xsd:string) as ?CP_)
      BIND (STRDT(?Latitud,xsd:float) as ?lat_)
      BIND (STRDT(?Longitud,xsd:float) as ?lon_)
      BIND (STRLANG(?Nombre, "es") as ?Nombre_)
      BIND (STRLANG(?Descripción, "es") as ?Descripción_)
      BIND (STRDT(?Fax,xsd:string) as ?FAX_)
    }Lenguaje del código: PHP (php)


    Este proceso con Tarql no es solo conversión entre formatos, sino mapping semántico:

    • Asignación de clases OWL.
    • Tipado de literales (fechas, coordenadas).
    • Creación de URIs persistentes.
    • Normalización del modelo de datos.

    Y demuestra cómo transformar datos tabulares en un grafo semántico reutilizable, alineado con una ontología propia y preparado para su integración con otras fuentes RDF.

    Ontología


    El mapeo se fundamentó en las clases, tipos y propiedades de una ontología OWL sobre patrimonio monumental, de elaboración propia, que tiene por objetivo su uso en el ámbito de todo el país.

    La motivación de la ontología de monumentos:

    • Para este y futuros proyectos necesitaba una ontología para monumentos que fuera completa y coherente.
    • DBpedia o Wikidata no ofrecen la coherencia lógica y semántica que buscaba.
    • Posee clases y tipos que se adaptan a España y a Europa Occidental en general, aunque puede ser ampliada fácilmente.

    La ontología, por tanto, no se limita a replicar categorías existentes, sino que proporciona una estructura conceptual coherente para describir bienes culturales de forma homogénea en todo el territorio nacional.

    Enriquecimiento Manual

    El csv de Lugares de interés de la Región de Murcia no contenía datos tales como fechas de creación, estilos, siglos, etc. Importantes para completar el grafo y por ello decido enriquecer “manualmente” los datos.

    La calidad de un Grafo de Conocimiento depende de la integridad de sus datos. Detecté carencias críticas en la fuente original (fechas, estilos) e implementé una fase de curación de datos, combinando scripts de normalización en Tarql con validación manual para asegurar la consistencia histórica.

    Extracción de Entidades


    Realizamos un reconocimiento de entidades a partir de los textos de descripción de cada lugar de interés o monumento, utilizando Dbpedia como grafo “generalista” y el Tesauro de bienes culturales del Ministerio de Cultura como diccionario especializado en el tema que tratamos.

    • Se trata de entity linking semántico.
    • Uso combinado de:
      • DBpedia (grafo generalista).
      • Tesauro MEC (vocabulario especializado).
    • Creación de relaciones semánticas reutilizables (skos:related).

    Este proceso transforma texto libre en conocimiento estructurado, permitiendo búsquedas y razonamientos imposibles en un enfoque tradicional.

    Cada monumento pasa así de ser una ficha descriptiva a convertirse en un nodo densamente conectado dentro de un grafo cultural. Con una rica red de relaciones semánticas que van más allá de la propia ontología.

    Como ejemplo del resultado podemos ver la entidad “Acueducto de los Arcos” y su texto descriptivo, del cual se lograron reconocer y extraer las entidades subrayadas, que luego son vinculadas mediante la propiedad skos:related:

    monu:Acueducto_de_los_Arcos a monu:Sitio_de_interés , monu:Arquitectura_Civil , monu:Acueducto , owl:NamedIndividual ;

    rdfs:comment «El Acueducto de los Arcos Fue declarado Monumento Histórico Artístico Nacional por Real Decreto 1757/1982 de 18 de junio. Conocido como el Acueducto de la Cequeta conduce el agua elevada por la Rueda de Alcantarilla desde la acequia de la Alquibla o Barreras, cruzando por la cañá en dirección hacia la BozNegra, por debajo del casco urbano. La Noria, solicitada por la Diócesis de Cartagena en 1451 al Concejo de Murcia y construida en 1457 ha sido susituida en varias ocaciones como muestran las diferentes reconstrucciones de la canal. La primera noria debió de cumplir su función hasta 1549, cuando fue construida tras la riada de 1545, que asoló la Villa de Alcantarilla. Tras varias renovaciones a lo largo de su historia, llegamos a 1956, fecha en la que la Sociedad Metalúrgica y Terrestre de Alicante instala la actual noria. Con la construcción de la variante de la N-340 se demolieron varios arcos, quedando dividido a ambos lados de la carretera. Las excavaciones arqueológicas que se están llevando a cabo en el entorno del acueducto muestran la existencia de restos romanos anteriores (estructuras arquitectónicas y material cerámicos de los siglos I al III d.c). El Acueducto esta formado por un conjunto de arcos de medio punto cuya función es sostener el cajal de ladrillo. El acueducto cuenta con un total de 22 arcadas desde la Rueda.»@es;


    Entidades extraídas:

    monu:Acueducto_de_los_Arcos   skos:related  
          <http://es.dbpedia.org/resource/N-340> , 
          <http://es.dbpedia.org/resource/Diócesis_de_Cartagena> , 
          <http://es.dbpedia.org/resource/1549> , 
          <http://es.dbpedia.org/resource/Monumento_Histórico_Artístico_Nacional> , 
          <http://es.dbpedia.org/resource/Alquibla> , 
          <http://es.dbpedia.org/resource/1545> , 
          <http://es.dbpedia.org/resource/Monumento_Histórico> , 
          <http://es.dbpedia.org/resource/1457> , 
          <http://es.dbpedia.org/resource/Rueda_de_Alcantarilla> , 
          <http://es.dbpedia.org/resource/1982> , 
          <http://tesauros.mecd.es/tesauros/bienesculturales/1008125> , 
          <http://tesauros.mecd.es/tesauros/bienesculturales/1196792> , 
          <http://es.dbpedia.org/resource/1956> , 
          <http://es.dbpedia.org/resource/Real_Decreto> , 
          <http://es.dbpedia.org/resource/Monumento_Histórico_Artístico> , 
          <http://es.dbpedia.org/resource/1451> , 
          <http://es.dbpedia.org/resource/Acueducto> , 
          <http://es.dbpedia.org/resource/Alcantarilla> .Lenguaje del código: HTML, XML (xml)

    Tanto de Dbpedia como del Tesauro de Bienes Culturales
    conseguimos 8357 relaciones skos:related.


    En un ecomerce, diario, servicio virtual… el procedimiento para la construcción de un sistema de recomendación de productos o contenido comenzaría del mismo modo. 

    La Categorización Inductiva

    Puesto que tanto los conceptos del Tesauro como las entidades de Dbpedia tienen una relación de pertenencia a Categorías que las engloban, me pareció buena idea dotar de esa capa de abstracción lógica y semántica a cada lugar de interés o monumento.

    Las categorías funcionan como una ontología ‘inducida’, permitiendo agrupar entidades heterogéneas bajo conceptos compartidos sin necesidad de definirlos explícitamente en la ontología original.

    Por ejemplo. gracias a conectar nuestros monumentos con Dbpedia, el sistema ‘aprendió’ automáticamente que el «Mármol de Macael«‘ y el «Ladrillo» son «Materiales de Construcción«, permitiendo crear un filtro de búsqueda por materiales sin haber etiquetado manualmente ni un solo monumento. Esto nos permite un comportamiento semántico avanzado.

    Aquí podemos ver como diversas entidades extraídas quedan subsumidas bajo una categoría común, en este caso “Materiales de construcción”:

    <http://es.dbpedia.org/resource/Categoría:Materiales_de_construcción>:
                <http://es.dbpedia.org/resource/Teja_árabe>
                <http://es.dbpedia.org/resource/Puerta_del_Perdón>
                <http://es.dbpedia.org/resource/Acero>
                <http://es.dbpedia.org/resource/Mármol_de_Macael>
                <http://es.dbpedia.org/resource/Acero_corten>
                <http://es.dbpedia.org/resource/Hebilla>
                <http://es.dbpedia.org/resource/Ladrillo>
                <http://es.dbpedia.org/resource/Vidrio>
                <http://es.dbpedia.org/resource/Mármol_de_Carrara>
                <http://es.dbpedia.org/resource/Acero_inoxidable>
                <http://es.dbpedia.org/resource/Verja>
                <http://es.dbpedia.org/resource/Mármol>
                <http://es.dbpedia.org/resource/Cristal>
                <http://es.dbpedia.org/resource/Tapial>
                <http://es.dbpedia.org/resource/Puerta>Lenguaje del código: HTML, XML (xml)


    De igual modo para las vinculaciones hechas con el Tesauro de Bienes Culturales:

    <https://tesauros.cultura.gob.es/tesauros/bienesculturales/1001184> Elemento arquitectónico:
          <http://tesauros.mecd.es/tesauros/bienesculturales/1008524> Suelo
          <http://tesauros.mecd.es/tesauros/bienesculturales/1001323> Bóveda
          <https://tesauros.cultura.gob.es/tesauros/bienesculturales/1005161> Pavimento
          <https://tesauros.cultura.gob.es/tesauros/bienesculturales/1007537> Moldura
          <https://tesauros.cultura.gob.es/tesauros/bienesculturales/1001096> LadrilloLenguaje del código: HTML, XML (xml)


    Frontend impulsado por Backend Semántico


    Uno de los objetivos era llevar esta estructura de grafo a una página web. Es decir, crear una web basada en grafo de conocimiento que utilizara las clases, tipos y propiedades para construir la arquitectura de contenido:

    • Una web generada desde un grafo.
    • Arquitectura de contenidos basada en clases y propiedades.
    • Navegación semántica.
    • Recomendaciones por tipología, estilo, ubicación.
    • Filtros basados en relaciones inferidas.


    Los menús reflejan las clases y propiedades principales de la ontología:


    Las páginas de detalle incluyen el texto de la descripción, clases y categorías de la ontología, recomendaciones en base a las tipologías, ubicaciones, estilo, etc…


    Gracias a la extracción de entidades, en la parte inferior, tenemos relaciones adicionales:


    Podemos consultar sus definiciones en Dbpedia o en el Tesauro y también son útiles para hacer filtrado de lugares de interés por esas relaciones extraídas:


    Se incluye una línea de tiempo en la que desplegar los monumentos por tipos y estilos según su fecha de creación o construcción:


    También una sección donde visualizar la ontología, las entidades, y las relaciones extraídas:


    Tenemos una sección especial para navegar con las entidades y las categorías extraídas:


    Y se incluye un punto SPARQL para realizar consultas:

    Estadísticas del proyecto

    Sitios de interés461
    Entidades extraídas8.357
    Categorías dbpedia135
    Categorías Tesauro474
    Número de triples2.6181
    Categorías navegables Ontología135
    Categorías navegables Extracción8.357

    Aplicaciones prácticas

    • Portales culturales semánticos.
    • Turismo inteligente.
    • Recomendadores culturales.
    • Integración con GIS.
    • Análisis de patrimonio por épocas, estilos o materiales.
    • Enriquecimiento automático de catálogos.
    • Sistemas de recomendación en ecommerce y webs.

    Qué demuestra este proyecto:

    • Dominio de Web Semántica.
    • Transformación de datos reales.
    • Modelado ontológico.
    • SPARQL avanzado.
    • Entity linking.
    • Publicación web basada en grafos.
  • Conectando pasado y presente: Un Viaje de SKOS a SPARQL por la Toponimia Histórica de España

    ¿No sería interesante poder visualizar en un mapa los nombres históricos de los lugares, ciudades y asentamientos de la Península Ibérica, las Islas Canarias y Baleares? ¿Filtrar por épocas y culturas y conocer los nombres con que llamaban los antiguos pobladores al lugar donde vivían?

    Ese es el objetivo central de este proyecto: construir un grafo unificado de toponimia histórica, conectando con los Tesauros MEC, con Wikidata, con mi ontología de lugares de España y con mi grafo de monumentos, para permitir exploraciones semánticas avanzadas y visualización geográfica en tiempo real.


    El Problema y el Objetivo


    Los tesauros MEC incluyen vinculación (LOD) hacia dbpedia en inglés, geonames, Getty Vocabularies, Linked Data Service de la Bbiblioteca del Congreso de EEUU y un largo etc de otros tesauros y vocabularios controlados.


    «59070 resultados para la propiedad skos:closeMatch»

    Sin embargo, los Tesauros MEC no incluyen directamente coordenadas geográficas que podamos usar para proyectar en un mapa. La dificultad, por tanto, estriba en vincular los datos culturales aislados (Tesauros) con datos geográficos actuales (Wikidata/Grafo) para darles un uso práctico.


    Definición de los Tesauros Mec

    Los Tesauros MEC del Ministerio de Cultura son vocabularios controlados basados en SKOS, diseñados para evitar ambigüedades terminológicas (sinónimos, polisemia…) y describir con precisión entidades culturales.

    En este proyecto empleo especialmente dos:


    El Tesauro de Toponimia Histórica contiene 1.191 conceptos, y son estos los que pretendemos geolocalizar. De los 1.191 algunos son divisiones territoriales que no podemos vincular con ninguna actual.


    De ellos, 1.132 son efectivamente entidades que podemos vincular puntualmente con lugares actuales (ciudades antiguas, asentamientos, topónimos). Y 884 incluyen ya una vinculación con el Tesauro Geográfico mediante skos:relatedMatch.


    El Tesauro Geográfico, por su parte, posee 45.847 conceptos skos, referidos a entidades geográficas del mundo. Un futuro proyecto podría consistir en vincular completamente todos los conceptos a Wikidata y Dbpedia. De momento nos centraremos en los que refieren a España.


    Preparación: cargando los RDF en Apache Jena Fuseki


    Para poder realizar consultas y transformaciones con libertad, creo un dataset TDB2 en Apache Jena Fuseki, donde cargo los RDF de los tesauros previamente descargados de aquí.

    Una vez cargados, analizo su estructura SKOS y las propiedades que conectan Toponimia Histórica con el Tesauro Geográfico. La clave aquí es skos:relatedMatch, que utilizo como base para construir relaciones semánticas más funcionales para adaptarse a este y a otros de mis proyectos.

    A partir de aquí ya podríamos realizar una consulta que salte entre grafos y servicios SPARQL para rescatar las coordenadas del lugar actual donde se encontraba el lugar histórico.

    El Desafío: Conectar Mundos Distintos

    El Tesauro de Toponimia Histórica utiliza la propiedad skos:relatedMatch para vincular conceptos históricos (ej. «al-Faray») con sus equivalentes geográficos actuales dentro del propio catálogo de tesauros del MEC. Sin embargo, este último carece de información espacial de alta calidad (coordenadas, jerarquía administrativa) necesaria para la visualización en un mapa.

    La solución fue establecer un puente hacia el Grafo de Lugares de España (alineado con Wikidata), que sí contiene las propiedades geográficas y espaciales clave (como wdt:P625 para coordenadas, y relaciones de contención provincial/autonómica).

    Metodología de Emparejamiento (Entity Matching)


    Para lograr esta interconexión vital, se aplicó una metodología en dos pasos que capitaliza la vinculación existente en el Tesauro y la extiende al ecosistema LOD:

    1. Transformación Interna y Reclasificación.
      • Identificación y Filtrado: Se filtraron los 884 conceptos de tipo lugares:Lugar_Histórico que poseían la propiedad skos:relatedMatch con el Tesauro Geográfico.
      • Creación de la Propiedad Semántica: La propiedad skos:relatedMatch fue transformada en la nueva propiedad lugares:Se_refiere_a_lugar_actual. Esto no es solo un cambio de nombre; es una promoción semántica que reinterpreta una relación léxica (SKOS) como una relación ontológica de referencia.
    2. La Vinculación Crítica con Wikidata (owl:sameAs)
      • Heurísticas de Vinculación: Se emplearon heurísticas (basadas en coincidencia de etiquetas preferentes y, donde era posible, coordenadas geográficas si estaban disponibles) para asegurar la máxima precisión.
      • Resultado: Se generaron 913 relaciones owl:sameAs, formalizando la equivalencia entre las entidades.

    Este fue el paso esencial que transformó el dataset en Linked Open Data. Utilizando la lista de los 884 lugares geográficos de referencia (ya seleccionados en el paso anterior), se ejecutó el proceso de Entity Matching para conectarlos con el Grafo de Lugares de España, que está alineado con Wikidata.

    Ejemplo de Creación de LOD:

    
    <http://tesauros.mecd.es/tesauros/geografico/1128352> owl:sameAs <http://www.wikidata.org/entity/Q23982870> .Lenguaje del código: HTML, XML (xml)

    Creación de la Propiedad Inversa y la Federación de Consultas


    Al establecer la relación owl:sameAs, el valor real de este proceso se desbloqueó:

    1. Conexión de Coordenadas: Ahora, una consulta puede saltar del nombre histórico (al-Faray) a la entidad de referencia del Tesauro, luego a su entidad equivalente en Wikidata (owl:sameAs) y, finalmente, rescatar la coordenada precisa (wdt:P625).
    2. Habilitación de la Bidireccionalidad: Se diseñó y construyó la propiedad inversa lugares:Tiene_nombre_histórico mediante una consulta CONSTRUCT en SPARQL:
    construct {
       ?a lugares:Tiene_nombre_histórico ?b
     }
          WHERE {
          ?b a lugares:Lugar_Histórico.
          ?b lugares:Se_refiere_a_lugar_actual ?lugartesauro.
          ?lugartesauro owl:sameAs ?a.
     }


    Esta propiedad inversa es fundamental. Permite que cualquier lugar actual en el mapa sea consultado para descubrir los nombres históricos que se le atribuyeron a lo largo del tiempo, facilitando la exploración de datos y la creación de la interfaz de usuario.

    El emparejamiento de entidades fue la llave para transformar un conjunto de datos estático y aislado en un recurso dinámico y federable, base de la potente capacidad de exploración semántica del proyecto.

    Esto abre la puerta a las consultas de doble salto:

    Lugar histórico → lugar actual → coordenadas.

    lugar actual → coordenadas →Lugar histórico


    Alineación con mi ontología de Edades y Culturas Arqueológicas


    El Tesauro de Toponimia Histórica utiliza skos:narrower, skos:broader y skos:member como mecanismos de agrupación semántica. Ejemplo: Antigüedad tardía reúne bajo sí multitud de topónimos.

    Aprovecho esta estructura para integrarla con mis propias clases:

    • monu:Antigüedad_tardía
    • (y el resto de Edades y Culturas Arqueológicas)

    Creo nuevas propiedades semánticas:

    • lugares:LugHistóricoÉpoca
    • lugares:LugHistóricoCultura


    Ejemplo de construcción:

    CONSTRUCT {
      ?b a lugares:Lugar_Histórico ;
         lugares:LugHistóricoÉpoca monu:Antigüedad_tardía .
    }
    WHERE {
      <http://tesauros.mecd.es/tesauros/toponimiahistorica/faceta/1211794> skos:member ?b .
    }Lenguaje del código: HTML, XML (xml)


    Rindiéndonos resultados como este:

    <http://tesauros.mecd.es/tesauros/toponimiahistorica/1212861>
            a                          lugares:Lugar_Histórico ;
            lugares:LugHistóricoÉpoca  monu:Antigüedad_tardía .Lenguaje del código: HTML, XML (xml)

    Cada concepto en la ontología de monumentos tiene sus descripciones que se utilizan en la aplicación web, como texto descriptivo.

    Generamos dos propiedades adicionales, que nos permiten agrupar directamente desde nuestros conceptos de Edades y Culturas arqueológicas y señalar los lugares históricos:

    • monu:Cultura_Arque_tiene_Lugares_Históricos
    • monu:Epoca_tiene_Lugares_Históricos


    Búsqueda por Comunidades Autónomas gracias a la ontología de lugares

    La capacidad semántica de la ontología de lugares de España nos va a permitir hacer búsquedas de lugares históricos por Comunidades Autónomas, aunque también podría hacerse por Provincias…

    Mi ontología de geográfica permite inferir pertenencias jerárquicas:

    • lugar → municipio
    • municipio → provincia
    • provincia → CCAA

    Gracias a estas relaciones, puedo recuperar todos los lugares históricos situados dentro de una Comunidad Autónoma, aunque su ubicación provenga de diferentes rutas jerárquicas (P131, capitalidad, contención semántica…).

    La consulta lo hace de forma sistemática recorriendo todas las vías de inferencia. Buscando sistemáticamente cualquier lugar actual que esté situado dentro de la Comunidad Autónoma utilizando para ello las propiedades de la Ontología de Lugares de España.


    Hispania Romana: visualización de asentamientos por provincias romanas


    También podemos visualizar los asentamientos de la época romana dentro de las propias divisiones administrativas de la época. Aprovecho para construir y utilizar Posee_entidades_menores a partir de las relaciones skos: del Tesauro de Toponimia Histórica.

    Construyo relaciones del tipo:

    lugares:Posee_entidades_menoresLenguaje del código: CSS (css)

    Para representar provincias o regiones romanas del Tesauro de Toponimia Histórica y sus ciudades subordinadas.

    Esto permite ver, por ejemplo:

    Las ciudades romanas asociadas a la provincia Carthaginensis, y su correspondencia actual en el mapa.


    ¿Qué restos (monumentos) estuvieron en qué ciudades antiguas?


    Como experimento de razonamiento deductivo semántico me propuse cruzar el grafo de monumentos con los lugares históricos con el fin de intentar crear una relación entre esos lugares históricos y los restos que pudieron haber pertenecido a esa ciudad o asentamiento y que tenemos ubicados en sus lugares actuales.

    Como experimento, cruzo:

    • Mi grafo de monumentos.
    • Mi grafo de lugares actuales.
    • Mi grafo de lugares históricos.
    • Las Edades/Culturas arqueológicas.

    La lógica es:

    • Un monumento está situado en un lugar actual.
    • Ese monumento pertenece a una época histórica.
    • Un lugar histórico también pertenece a la misma época.
    • Por tanto, probablemente ese monumento estuvo en ese asentamiento histórico.

    Consulta:

    SELECT *
    WHERE {
      ?a a monu:Sitio_de_interés ;
         monu:Esta_situado_en ?b ;
         monu:Monumento_tiene_epoca ?epoca .
      SERVICE <https://javiermurcia.tech/fuseki/Lugares-Historicos/> {
        ?b lugares:Tiene_nombre_histórico ?nomhisto .
        ?nomhisto lugares:LugHistóricoÉpoca ?epoca .
      }
    }Lenguaje del código: HTML, XML (xml)

    Se obtienen 2.594 posibles emparejamientos. No todos son perfectos, pero muchos son sorprendentemente plausibles.

    Con este experimento de inferencia he intentado ir más allá de la vinculación directa y aplicar razonamiento deductivo (mediante constructs o queries con patrones complejos) para descubrir nuevas relaciones (monu:Estuvo_situado_en).

    En efecto, la calidad del razonamiento depende de la granularidad y la consistencia de las ontologías de origen, lo que abre una línea de trabajo futuro para aplicar reglas de inferencia más sofisticadas.

    Visualización y acceso público

    • Leaflet para mapas interactivos
    • YASGUI para ejecutar consultas SPARQL en la web


    Métricas de Vinculación y Curación

    Conceptos skos en Tesauro Toponimia Histórica1191
    Con relación skos:relatedMatch a Tesauro Geográfico884
    Con la propiedad lugares:Se_refiere_a_lugar_actual vinculados913


    Conclusión: un proyecto que une semántica, arqueología y territorio


    Este proyecto demuestra el potencial de la web semántica y el modelado ontológico para:

    • Recuperar memoria histórica del territorio.
    • Integrar datos dispersos en un grafo coherente.
    • Permitir exploración geográfica avanzada.
    • Establecer conexiones nuevas entre lugares, culturas y épocas.
    • Generar conocimiento inédito mediante razonamiento semántico.

    Los datos y los constructs generados están disponibles públicamente.

  • Datos enlazados y relaciones humanas en la historia

    Los grandes grafos de conocimiento como Wikidata son una enorme acumulación de datos estructurados esperando a ser interrogados. Si tenemos la paciencia y las habilidades para consultarlos podemos obtener conocimiento y valor, que a priori no teníamos, o mejor dicho: que no sabíamos que teníamos.

    Extraer valor de los datos y transformarlo en conocimiento humano es uno de mis objetivos. Con este proyecto me propongo realizar una exploración de datos abiertos y sondear las posibilidades de la web semántica para representar relaciones humanas, históricas y artísticas. En particular, aquellos que atesora Wikidata.

    En concreto me centraré en relaciones de “larga data”, aquellas que están fuera del alcance de los libros de historia, pero accesibles gracias a los grafos de conocimiento.

    Como profesional especializado en datos enlazados y SPARQL, quise crear una aplicación que visualizara genealogías y redes de discípulos utilizando Wikidata y Blazegraph.


    Algunos conceptos técnicos

    • Un grafo de conocimiento es, en esencia, una estructura compuesta de “entidades” y de las relaciones que estas tienen entre sí.
    • Aunque no es el único, existe un modelo de datos ampliamente extendido y estandarizado denominado RDF (Resource Description Framework ), usado para formalizar los grafos de conocimiento, modelo que utiliza Wikidata.
    • Para realizar las consultas, es decir preguntar al grafo, necesitamos un lenguaje estandarizado para la consulta de grafos RDF, este lenguaje se denomina SPARQL.
    • El grafo de conocimiento al que vamos a interrogar es Wikidata, que es una base de datos orientada a documentos, centrada en elementos que representan cualquier tipo de tema, concepto u objeto.
    • A cada elemento se le asigna un identificador persistente único llamado QID, que es un número entero positivo precedido por la letra mayúscula «Q». Aunque los QIDs no resultan muy amigables para nosotros los humanos, permiten distinguir cada elemento sin favorecer ningún idioma en particular.
    • En Wikidata las propiedades que relacionan estos elementos se construyen de un modo semejante. Cada propiedad tiene un identificador numérico precedido por una P mayúscula y una página en Wikidata con etiqueta, descripción, alias y declaraciones opcionales.



    Ejemplo: Q720 (Genghis Kan) -> P40 (hijo o hija) -> Q186581 -> (Jochi)

    • La tienda triple y base de datos que utiliza Wikidata para ejecutar las consultas se llama Blazegraph. De ella utilizaremos especialmente la RDF GAS API, de la que hablaremos posteriormente.


    Todas estas tecnologías unidas nos permitirán realizar consultas complejas que nos revelarán patrones y conexiones que serían imposibles de detectar con bases de datos tradicionales. Así qué pongámonos manos a la obra.


    “A diferencia de una base de datos convencional, Wikidata no guarda información aislada, sino relaciones semánticas. Esto permite navegar las conexiones entre entidades —personas, lugares, obras— y realizar análisis relacional de red, genealogías o linajes conceptuales.”


    Genealogías con Wikidata

    La idea de mi experimento sobre genealogías proviene y se inspira en las consultas que se encuentran en la wiki Wikidata:SPARQL query service y en las páginas de ejemplos de consultas sparql avanzadas de Wikidata. Un lugar muy recomendable donde aprender SPARQL e inspirarse con las posibilidades de consulta en Wikidata.

    Allí podemos encontrar interesantes consultas sobre taxones, y diversos ejemplos y explicaciones sobre la RDF GAS API.


    Pero para empezar nos fijaremos en la consulta, Children of Genghis Khan (Hijos de GenGis khan):

    #defaultView:Graph
    PREFIX gas: <http://www.bigdata.com/rdf/gas#>
    SELECT ?item ?itemLabel ?pic ?linkTo
    WHERE {
      SERVICE gas:service {
        gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" ;
                    gas:in wd:Q720 ;
                    gas:traversalDirection "Forward" ;
                    gas:out ?item ;
                    gas:out1 ?depth ;
                    gas:maxIterations 4 ;
                    gas:linkType wdt:P40 .
      }
      OPTIONAL { ?item wdt:P40 ?linkTo }
      OPTIONAL { ?item wdt:P18 ?pic }
      SERVICE wikibase:label {bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" }
    }
    Lenguaje del código: PHP (php)


    Aquí podemos verla en acción.


    Con ella se rescatan de manera sistemática los hijos de los hijos, comenzando con la entidad wd:Q720, Gengis Kahn, y se muestran en forma de visualización.


    Descendientes y Ascendientes


    Estas consultas utilizan los algoritmos de la RDF GAS API Algortimos que se encuentran disponibles en Blazegraph, y que nos permiten realizar Análisis de Grafos (Graph Analytics) manejando algoritmos avanzados como el SSSP – Single-Source Shortest Path, crucial para buscar rutas, influencias, y comunidades en grandes redes de datos.


    En esencia la consulta recorre la nodos a través de la propiedad
    hijo o hija (P40) (familiar descendiente en primer grado de parentesco) Partiendo de la entidad Q720 que se corresponde con el personaje histórico GenGis khan.


    Hay que tener en cuenta que en Wikidata hay aproximadamente un millón de entidades que representan a seres humanos con la propiedad P40. Eso nos abre muchas posibilidades a la hora de explorar líneas genealógicas profundas, sobre todo entre la aristocracia de cualquier parte del mundo, ya que es el grupo de seres humanos sobre el que mas datos tenemos en dicho grafo.


    El uso de estos identificadores únicos (URIs/Entidades) como
    wd:Q47595 Alfonso X de Catilla y wdt:P40 propiedad hijo/a de,
    es el pilar de la Web Semántica y constituye una de sus grandes virtudes, a saber: la capacidad de referenciar de forma unívoca
    la misma cosa en cualquier idioma o contexto.”

    #defaultView:Graph
    PREFIX gas: <http://www.bigdata.com/rdf/gas#>
    SELECT ?item ?itemLabel ?pic ?linkTo # Variables a encontrar
    WHERE {
      SERVICE gas:service {
        gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" ;
                    gas:in wd:Q720 ; # Entidad de entrada  (GenGis khan)
                    gas:traversalDirection "Forward" ; #"Reverse" Alternar una y otra opción nos permite encontrar antecesores o sucesores 
                    gas:out ?item ; # se utiliza para vincular los valores descubiertos por el algoritmo GAS a los conjuntos de soluciones.
                    gas:out1 ?depth ;
                    gas:maxIterations 4 ; #el número máximo de iteraciones antes de que finalice el algoritmo GAS
                    gas:linkType wdt:P40 . # Sólo pasará por bordes que tenga esta propiedad (Hijo o hija)
      }
      OPTIONAL { ?item wdt:P40 ?linkTo } # Vinculamos las entidades encontradas entre sí mediante la propiedad P40
      OPTIONAL { ?item wdt:P18 ?pic }  # Opcionalmente seleccionamos una imagen, si la hay
      SERVICE wikibase:label {bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" }
    }
    Lenguaje del código: PHP (php)


    Mi consulta incluye optimizaciones SPARQL fundamentales para mejorar la experiencia de usuario y la calidad de los resultados de la consulta, como es el uso de SAMPLE, necesario para manejar el caso de qué una de nuestras entidades (persona) posea múltiples valores para imágenes o fechas. Y el uso de GROUP BY para realizar agrupaciones de los resultados.

    PREFIX bd: <http://www.bigdata.com/rdf#>
    PREFIX wikibase: <http://wikiba.se/ontology#>
    PREFIX schema: <http://schema.org/>
    PREFIX wdt: <http://www.wikidata.org/prop/direct/>
    PREFIX wd: <http://www.wikidata.org/entity/>
    PREFIX gas: <http://www.bigdata.com/rdf/gas#>
    SELECT ?item ?itemLabel ?linkTo ?depth ?comment (SAMPLE (?EjemfechaNaci) AS ?fechaNaci) (SAMPLE (?pic) AS ?unica_pic)
    WHERE
    {
    SERVICE gas:service {
      gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" ;
      gas:in wd:Q47595; #Alfonso X
      gas:traversalDirection "Forward";
      gas:out ?item;
      gas:out1 ?depth;
      gas:maxIterations 3;
      gas:linkType wdt:P40; #descendiente
    }
    OPTIONAL { ?item wdt:P40 ?linkTo.}
    OPTIONAL { ?item wdt:P18 ?pic.}
    OPTIONAL { ?item wdt:P569 ?EjemfechaNaci}
    OPTIONAL{?item schema:description ?comment.
    FILTER (lang(?comment) = 'es').}
    SERVICE wikibase:label { bd:serviceParam wikibase:language"[AUTO_LANGUAGE],es,en,ar,be,bg,bn,ca,cs,da,de,el,fr,et,fa,fi,he,hi,hu,hy,id,it,ja,jv,ko,nb,nl,eo,pa,pl,pt,ro,ru,sh,sk,sr,sv,sw,te,th,tr,uk,yue,vec,vi,zh".}
    }
    GROUP BY ?item ?itemLabel ?linkTo ?unica_pic ?depth ?comment ?fechaNaci
    ORDER BY ?depth
    LIMIT 200
    Lenguaje del código: PHP (php)


    Mediante javascript alternamos en la consulta SPARQL la entidad sobre la que vamos a recabar información, y modificando el parámetro gas:traversalDirection entrte «Forward» o «Reverse» buscamos descendientes o ascendientes.


    El manejo de gas:traversalDirection nos permite comprender
    la multi-direccionalidad de las relaciones en los grafos. Y la capacidad de navegación compleja (ascendientes vs. descendientes) en los modelos de conocimiento.


    Algo que me pareció interesante incluir fue una línea temporal en la que aparecieran los personajes y familiares por fecha de nacimiento, añadiendo esa dimensión temporal que completa la percepción de la genealogía, de la descendencia y ascendencia. Para ello necesitaba la propiedad wdt:P569 (fecha de nacimiento) de cada persona.


    De esta manera enriquecíamos la experiencia de la consulta y transformábamos los datos estáticos en narrativas dinámicas.

    Genealogías conectadas


    Un parámetro interesante de la RDF GAS API que no habíamos utilizado hasta ahora es gas:target, con él podemos señalar un vértice de destino, y ponerlo funcionar junto a gas:in, que ya hemos utilizado, y que señala el vértice de inicio.


    De hecho, el algoritmo que estamos usando se denomina Single Source Shortest Path y calcula el camino más corto a cada vértice del grafo. Dicho algoritmo lo tenemos seleccionado en esta línea de la consulta SPARQL:

    gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" ;Lenguaje del código: CSS (css)


    A partir de aquí, nuestra aplicación de genealogía puede confrontar dos entidades, dos personas alejadas en el tiempo, y buscar cuál es el camino más corto a través de la propiedad P40 entre ellas dos, si existe.

    PREFIX gas: <http://www.bigdata.com/rdf/gas#>
    PREFIX bd: <http://www.bigdata.com/rdf#>
    PREFIX wikibase: <http://wikiba.se/ontology#>
    PREFIX schema: <http://schema.org/>
    PREFIX wdt: <http://www.wikidata.org/prop/direct/>
    PREFIX wd: <http://www.wikidata.org/entity/>
    SELECT ?item ?itemLabel ?linkTo ?comment (SAMPLE (?pic) AS ?unica_pic)
    WHERE
    {
    SERVICE gas:service {
      gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" ;
      gas:in  wd:Q47595; #Alfonso X
      gas:traversalDirection "Forward" ;
      gas:target wd:Q19943;  #Juan Carlos I
      gas:out ?item ;
      gas:out1 ?depth ;
      gas:maxIterations 35 ;
      gas:linkType wdt:P40 ;
    }
    OPTIONAL { ?item wdt:P40 ?linkTo.}
    OPTIONAL { ?item wdt:P18 ?pic.}
    OPTIONAL { ?item schema:description ?comment.
    FILTER (lang(?comment) = 'es').}
    SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],es,en,ar,be,bg,bn,ca,cs,da,de,el,fr,et,fa,fi,he,hi,hu,hy,id,it,ja,jv,ko,nb,nl,eo,pa,pl,pt,ro,ru,sh,sk,sr,sv,sw,te,th,tr,uk,yue,vec,vi,zh". }
    }
    GROUP BY ?item ?itemLabel ?linkTo ?unica_pic ?comment
    Lenguaje del código: PHP (php)

    Siempre basándonos en los datos existentes en Wikidata, la consulta rinde resultados sorprendentes para muchos personajes históricos.

    Por ejemplo existe una relación genealógica entre Carlo Magno y Nicolás II de Rusia (último Zar). Y otra entre Ragnar Lothbrok e Isabel I de Inglaterra


    Por otra parte, por ser una consulta que requiere varios segundos en su ejecución, en ocasiones, el servidor de Wikidata rechazará la consulta. Podemos repetirla hasta que se resuelva y nos dé resultados.


    Cuando los personajes se encuentran muy alejados históricamente habremos de configurar un número de iteraciones alto para poder llegar a una conclusión. Es por ello que en la aplicación web tenemos un control denominado Nº máximo de iteracciones, donde modificar el parámetro gas:maxIterations.


    De Leonardo a Giacometti: redes de aprendizaje a través de los siglos

    De las diversas propiedades que existen en Wikidata y que interrelacionan a numerosas entidades, hay una que llamó mi atención por el valor histórico y cultural que representa.

    Hablo de la propiedad P802 (tiene discípulo). Ella expresa la relación que se da entre algún maestro y un alumno destacado del primero. Tras mucha experimentación y tanteo he seleccionado a varios artistas e intelectuales de los que parten larguísimas relaciones maestro-discípulo a través de los siglos.


    Hablamos de relaciones directas entre personas. Gestos, palabras y enseñanzas compartidas cara a cara desde Leonardo hasta Modigliani o Giacometti. ¿Han perdurado los gestos y ademanes del Renacimiento en los artistas del siglo XX?

    PREFIX gas: <http://www.bigdata.com/rdf/gas#>PREFIX bd: <http://www.bigdata.com/rdf#>
    PREFIX wikibase: <http://wikiba.se/ontology#>
    PREFIX schema: <http://schema.org/>
    PREFIX wdt: <http://www.wikidata.org/prop/direct/>
    PREFIX wd: <http://www.wikidata.org/entity/>
    SELECT ?item ?itemLabel ?linkTo ?depth ?comment (SAMPLE (?EjemfechaNaci) AS ?fechaNaci) (SAMPLE (?pic) AS ?unica_pic)
    WHERE
    {
    SERVICE gas:service {
      gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" ;
      gas:in wd:Q762  ; #Leonardo Da Vinci
      gas:traversalDirection "Forward" ;
      gas:out ?item ;
      gas:out1 ?depth ;
      gas:maxIterations 15 ;
      gas:linkType wdt:P802 ;
    }
    OPTIONAL { ?item wdt:P802 ?linkTo.}
    OPTIONAL { ?item wdt:P18 ?pic.}
    OPTIONAL { ?item wdt:P569 ?EjemfechaNaci }
    OPTIONAL { ?item schema:description ?comment.
    FILTER (lang(?comment) = 'es').}
    SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],es,en,ar,be,bg,bn,ca,cs,da,de,el,fr,et,fa,fi,he,hi,hu,hy,id,it,ja,jv,ko,nb,nl,eo,pa,pl,pt,ro,ru,sh,sk,sr,sv,sw,te,th,tr,uk,yue,vec,vi,zh". }
    }
    GROUP BY ?item ?itemLabel ?linkTo ?unica_pic ?depth ?comment ?fechaNaci
    ORDER BY ?depth
    LIMIT 200
    Lenguaje del código: PHP (php)

    Por su puesto, todas las consultas se pueden utilizar en el punto sparql de Wikidata: https://query.wikidata.org/, si además se le añade: #defaultView:Graph en la parte superior de la consulta nos mostrará el resultado como visualización.

    Aun así he añadido un editor SPARQL con la librería Yasgui. En él podemos echar un vistazo, modificar… cada consulta que usamos en la aplicación.

    Conclusiones

    Este proyecto muestra como los grandes grafos de conocimiento no son solo útiles para consultar sino que además se puede extraer de ellos conocimiento nuevo, o al menos conocimiento que antes no era explícito.

    Por su parte, vemos como el lenguaje de consultas SPARQL no solo sirve para extraer datos, sino que puede generar resultados que nos permiten contar auténticas historias con grafos.

    En definitiva, este proyecto demuestra cómo, combinando datos enlazados y visualización semántica de datos, es posible crear aplicaciones interactivas con un alto valor exploratorio e histórico.


    Aplicaciones

    Algunos posibles usos:

    • Visualización de redes de investigadores o autores.
    • Árboles de linaje en historia o literatura.
    • Análisis de conexiones entre instituciones o proyectos culturales.
    • Auditoría o enriquecimiento semántico de bases de datos empresariales.

    Si te interesa aplicar este tipo de análisis semántico en tus propios datos o proyectos culturales, científicos o empresariales, puedo ayudarte a diseñar la arquitectura y las consultas adecuadas.

    Si deseas desarrollar una aplicación basada en datos enlazados o explorar el potencial de Wikidata para tu proyecto, contáctame.