Autor: javiermurcia

  • 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.