Categoría: blog

blog

  • Razonamiento sobre Datos: Transformando Información Cruda en Conocimiento Inteligente

    Vivimos en la era del Big Data. Las empresas y organizaciones acumulan millones de registros diarios, pero tener datos guardados en una base de datos no es sinónimo de tener respuestas. Para dar el salto de la simple acumulación a la verdadera inteligencia, necesitamos aplicar el razonamiento sobre datos.

    Pero, ¿qué significa exactamente este concepto y cómo puede revolucionar la forma en que extraemos valor de nuestra información?

    ¿Qué es el Razonamiento sobre Datos?

    El razonamiento sobre datos (o inferencia semántica) es el proceso mediante el cual un sistema informático utiliza reglas lógicas y ontologías para descubrir nueva información que no estaba explícitamente guardada en la base de datos original.

    En bases de datos relacionales tradicionales (SQL), si haces una consulta, solo obtienes lo que alguien escribió previamente. Con el razonamiento lógico sobre datos estructurados en grafos de conocimiento, el sistema es capaz de deducir nuevas verdades. Es decir, por cada dato que introduces, el motor de inferencia puede generar automáticamente decenas de datos implícitos.

    Para entender el verdadero poder de esta tecnología, veamos un ejemplo a gran escala.

    De la Teoría a la Práctica: Infiriendo 14 Millones de Relaciones

    Para demostrar la capacidad del razonamiento lógico sobre datos, diseñé un proyecto de Ingeniería de Conocimiento a Gran Escala utilizando información de Wikidata.

    El objetivo no era consultar un árbol genealógico existente, sino construir una genealogía ampliada partiendo de un conjunto mínimo de datos.

    El Punto de Partida: Datos Explícitos

    Tomé una muestra de casi un millón de personas en Wikidata. La única relación de parentesco directa que utilicé fue la propiedad básica: hijo/a de.

    Un sistema tradicional se quedaría ahí. Sabría quién es el padre y quién es el hijo, pero no sabría responder a la pregunta: «¿Quiénes son primos terceros en esta base de datos?».

    La Inferencia Semántica en Acción

    Diseñé una ontología ligera y un motor de inferencia basado en cláusulas lógicas. A través de operaciones de materialización de conocimiento (usando inserciones SPARQL en cascada), enseñé al sistema a razonar.

    La lógica subyacente es sencilla para un humano, pero procesarla a esta escala requiere una arquitectura robusta:

    Si A es mujer, y A es hermana de B, y B es madre de C; entonces el sistema deduce automáticamente que A es tía de C.

    Los Resultados del Razonamiento

    Gestionando la explosión combinatoria para no saturar la memoria del servidor, el motor procesó ese millón de entidades iniciales. ¿El resultado?

    • 14.647.450 de nuevas relaciones semánticas generadas.
    • Por cada dato explícito original, el sistema infirió 14 datos implícitos.
    • Logramos deducir relaciones lejanas de hasta tercer grado de consanguinidad (más de 1.3 millones de relaciones de «primos terceros»).
    Tipo de DatoCantidad OriginalConocimiento Inferido
    Nodos (Personas)~ 1.000.000
    Relaciones Explícitas3.275.201
    Nuevas Relaciones Deducidas14.647.450
    Total de Triples en el Grafo> 40.500.000


    Pasamos de un listado plano de nacimientos a una red semántica viva y explorable.

    ¿Por qué importa el Razonamiento sobre Datos en el mundo empresarial?

    La capacidad de modelar ontologías y aplicar deducción lógica no es un mero ejercicio académico. Es una ventaja competitiva crítica para múltiples sectores:

    • Sector Legal y Financiero: Detección de conflictos de intereses corporativos, rastreo de beneficiarios reales y prevención de fraude conectando puntos que aparentemente no estaban relacionados.
    • Investigación Biomédica: Descubrimiento de relaciones ocultas entre genes, proteínas y enfermedades a partir de literatura médica dispersa.
    • Gestión de Recursos Humanos y Redes: Análisis de influencia y liderazgo dentro de grandes organizaciones corporativas.

    Los grafos de conocimiento equipados con motores de razonamiento no solo almacenan información; la entienden, la expanden y generan inteligencia estructurada.

    Lleva tus datos al siguiente nivel

    Si tu organización maneja grandes volúmenes de información fragmentada y necesitas transformar tus bases de datos estáticas en grafos de conocimiento vivos, puedo ayudarte.

    Diseño ontologías a medida, implemento modelos de inferencia escalables y desarrollo infraestructuras técnicas basadas en Inteligencia Artificial Simbólica para que tus datos empiecen a trabajar para ti.

  • RAG Semántico: Conectando Modelos de Lenguaje (LLMs) con Grafos de Conocimiento.

    La Inteligencia Artificial Generativa ha prometido revolucionar la forma en que las empresas interactúan con su información. Sin embargo, cuando las organizaciones conectan modelos como ChatGPT o Gemini a sus documentos corporativos, tropiezan con un muro peligroso: las alucinaciones.

    Si le pides a una IA estándar que cruce la normativa legal de tu empresa con el historial de un cliente, es muy probable que invente datos, mezcle conceptos o dé respuestas plausibles pero falsas. En sectores como el legal, el farmacéutico o la administración pública, un error del 5% no es un margen de mejora; es un riesgo inasumible.

    La solución a este problema no es entrenar modelos más grandes, sino cambiar la arquitectura de datos subyacente. La respuesta se llama RAG Semántico impulsado por Grafos de Conocimiento.

    ¿Qué es RAG y por qué el enfoque tradicional se queda corto?

    RAG (Retrieval-Augmented Generation o Generación Aumentada por Recuperación) es una técnica que permite a una IA buscar información en tus bases de datos privadas antes de responder.

    En el RAG tradicional, los documentos se cortan en pedazos y se guardan como «vectores» (números). Cuando el usuario hace una pregunta, el sistema busca los fragmentos de texto que más se parecen estadísticamente a la pregunta y se los da a la IA para que redacte la respuesta.

    ¿El problema? La similitud estadística no es comprensión lógica. Si le preguntas a un RAG tradicional: «¿Qué medicamentos de nuestro catálogo interactúan negativamente con el ibuprofeno?», el sistema buscará textos donde las palabras «ibuprofeno» e «interacción» estén cerca. Si el catálogo es complejo, omitirá relaciones indirectas o inventará conexiones, porque no entiende qué es un medicamento ni cómo funciona la química.

    La solución: RAG Semántico y la IA Neuro-Simbólica

    Para que una IA deje de adivinar, necesitamos darle un «cerebro lógico». Aquí es donde entran los Grafos de Conocimiento y la Web Semántica.

    En un RAG Semántico (a menudo llamado GraphRAG), no cortamos los textos a ciegas. Primero, estructuramos la información de la empresa en una ontología. Modelamos las entidades (Pacientes, Contratos, Fármacos) y sus relaciones lógicas exactas.

    De este modo, creamos un sistema de IA Neuro-Simbólica:

    1. La parte Simbólica (El Grafo): Aporta lógica estricta, determinismo y hechos comprobables mediante consultas precisas (SPARQL).
    2. La parte Neuronal (El LLM): Aporta la comprensión del lenguaje natural para interactuar con el usuario de forma fluida.

    Cuando el usuario hace la misma pregunta sobre el ibuprofeno, el LLM no busca similitudes de texto; traduce la pregunta a una consulta lógica al grafo. El grafo devuelve hechos y relaciones exactas, y el LLM simplemente los traduce de vuelta a lenguaje humano. Cero alucinaciones. Trazabilidad absoluta.

    Caso de Uso Práctico: Datos Farmacéuticos (HealthKG)

    Un ejemplo claro de la necesidad de esta precisión es mi proyecto HealthKG, un grafo del ecosistema farmacéutico español.

    En este sector, cruzar datos de la Agencia Española de Medicamentos (AEMPS) con bases de datos globales (Wikidata, DBpedia) y ontologías médicas (como ATC o DOID) es un desafío monumental si se usan bases de datos relacionales.

    Al modelar este ecosistema como un Grafo de Conocimiento, un sistema RAG semántico puede navegar por las relaciones estructuradas para inferir de forma 100% precisa interacciones, duplicidades terapéuticas y vincular fármacos con biomarcadores, respondiendo a preguntas complejas con referencias exactas a las normativas vigentes. Puedes explorar la visualización y el modelado de este ecosistema en el caso de estudio de HealthKG«).

    Beneficios del RAG Semántico para tu organización

    Implementar esta arquitectura supone un salto cualitativo enorme:

    • Trazabilidad total (Explicabilidad): Cada afirmación de la IA está vinculada a un nodo específico de tu base de datos. Si la IA afirma algo, puedes ver exactamente de qué documento y relación lógica partió.
    • Inferencia de nuevo conocimiento: El grafo puede deducir relaciones implícitas gracias a la lógica de su ontología (algo que los vectores simples no pueden hacer).
    • Actualización en tiempo real: Si cambias un dato en el grafo (ej. una ley o el precio de un producto), la IA lo asimila instantáneamente, sin necesidad de ser re-entrenada.

    Conclusión

    El futuro de la IA empresarial no pasa por modelos de lenguaje que actúen como enciclopedias que memorizan textos, sino como interfaces inteligentes que consultan Grafos de Conocimiento rigurosos. Modelar la realidad de tu empresa de forma lógica es el único camino hacia una automatización segura y fiable.

    ¿Quieres implementar un sistema de IA que entienda tus datos sin inventar respuestas? Hablemos de la arquitectura semántica de tu proyecto.

  • SPARQL explicado con ejemplos reales (y ejecutables)

    SPARQL explicado con ejemplos reales (y ejecutables)

    Si trabajas con grafos de conocimiento, sabes que SPARQL no se aprende leyendo teoría, sino viendo cómo se resuelven problemas reales.

    En este artículo voy a explicarlo con ejemplos que uso en producción sobre:

    • Wikidata.
    • Grafos propios (patrimonio, lugares, genealogías)
    • Consultas federadas reales.
    • Casos complejos (inferencias, agregaciones, grafos distribuidos)

    Además, podrás ejecutar las consultas en vivo gracias a endpoints propios basados en Apache Fuseki + YASGUI.

    ¿Qué es SPARQL (en 30 segundos)?

    SPARQL es el lenguaje de consulta para RDF, equivalente a SQL en bases de datos relacionales, pero pensado para grafos.

    La idea clave:
    No consultas tablas → consultas relaciones (tripletas)

    1. Primer ejemplo real: consultar un grafo propio

    Vamos a empezar con algo sencillo: obtener monumentos y su municipio desde un grafo de patrimonio.

    
    PREFIX monu:  <http://www.monumentos.es/>
    PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
    
    SELECT DISTINCT *
    WHERE {
      ?monumento a monu:Sitio_de_interés.
      ?monumento rdfs:label ?label.
      ?monumento monu:Está_en_Municipio  ?municipio.
      ?municipio rdfs:label ?municipiolabel.
    }
    LIMIT 25
    Lenguaje del código: SQL (Structured Query Language) (sql)

    Qué está pasando aquí

    • Filtramos por tipo
    • Navegamos relaciones
    • Recuperamos etiquetas

    Ejecutar consulta en vivo: Abrir en YASGUI

    2. Consultar Wikidata con grafos: descendientes de Alfonso X

    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 200Lenguaje del código: PHP (php)

    Qué hace esto

    • Aplica Single Source Shortest Path (SSSP)
    • Parte de Alfonso X.
    • Recorre descendientes.

    Por qué es potente: estás haciendo análisis de grafos dentro de SPARQL.

    Ejecutar consulta en vivo: Abrir demo

    Consultas federadas: unir múltiples grafos

    PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
    PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
    prefix monu:  <http://www.monumentos.es/>
    prefix lugares: <http://www.monumentos.es/lugares/>
    PREFIX owl: <http://www.w3.org/2002/07/owl#>
    select (sample (?EjemplolugarActual) as ?lugarActual) ?monu ?labelMonu ?lugarHist ?labelHis ?labelActual ?point ?pointMonu ?image ?definition
    WHERE {
    ?monu monu:Estuvo_situado_en ?lugarHist.
    ?lugarHist lugares:LugHistóricoÉpoca monu:Edad_Antigua. # monu:Edad_del_Hierro
    ?lugarHist lugares:Se_refiere_a_lugar_actual ?EjemplolugarActual
      service <https://javiermurcia.tech/fuseki/tesauros-mec/> {
      ?lugarHist skos:prefLabel ?labelHis.
      ?lugarHist skos:definition  ?definition.
      FILTER (LANG (?labelHis) = 'es')
      }
      service <https://javiermurcia.tech/fuseki/lugares-espana/> {
      ?EjemplolugarActual rdfs:label ?labelActual.
      FILTER (LANG (?labelActual) = 'es')
      ?EjemplolugarActual <http://www.wikidata.org/prop/direct/P625> ?point.
      }
      service <https://javiermurcia.tech/fuseki/monumentos-espana/> {
      ?monu rdfs:label ?labelMonu.
      FILTER (LANG (?labelMonu) = 'es')
      ?monu <http://www.wikidata.org/prop/direct/P625> ?pointMonu.
      ?monu monu:Imagen ?image.
      }
    }group by ?lugarActual ?monu ?labelMonu ?lugarHist ?labelHis ?labelActual ?point ?pointMonu ?image ?definition
    limit 35Lenguaje del código: PHP (php)

    Qué está pasando

    Estás consultando varios grafos a la vez y unificando resultados en una sola query. La consulta va saltando por varios grafos hasta unificar lugares, monumentos y toponimia histórica

    Ejecutar consulta en vivo: Abrir demo

    Agregaciones: análisis de datos (estilo barroco)

    PREFIX owl: <http://www.w3.org/2002/07/owl#>
    PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
    PREFIX monu:  <http://www.monumentos.es/>
    SELECT (COUNT (?subject) as ?monu) ?lugar ?label
    WHERE {
      {
        ?subject a monu:Sitio_de_interés.
        ?subject monu:Monumento_tiene_estilo monu:Barroco.
        ?subject  monu:Está_en_Provincia ?lugar.
      }
      service <https://javiermurcia.tech/fuseki/lugares-espana/> {
        ?lugar rdfs:label ?label
        filter (lang (?label) = 'es')
      }
    }
    GROUP BY
    ?monu ?lugar  ?label
    order by desc ( ?monu)
    LIMIT 100Lenguaje del código: PHP (php)

    Aquí estás contando, agrupando y ordenando resultados: SPARQL también sirve para analítica.

    Ejecutar consulta en vivo: Abrir demo

    5. CONSTRUCT: crear nuevo conocimiento

    PREFIX monu:  <http://www.monumentos.es/>
    PREFIX lugares: <http://www.monumentos.es/lugares/>
    CONSTRUCT {
      ?nomhisto lugares:LugHistóricoÉpoca ?epoca .
    }
    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 .
      }
    }limit 20Lenguaje del código: HTML, XML (xml)

    No estás consultando datos: estás creando nuevos triples.

    Este tipo de consultas permite inferir conocimiento sin necesidad de motores OWL complejos.

    6. Caso complejo: genealogías + DBpedia

    PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
    PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
    PREFIX fami: <http://www.relacionesfamiliares/>
    SELECT  ?a  ?aLabel
    (SAMPLE (?pic) AS ?aejempic) (SAMPLE (?pic2) AS ?segudoejempic)(SAMPLE (?pic3) AS ?primoejempic) (SAMPLE (?pic4) AS ?PrimotercerPic) ?ParejaPrimo ?ParejaPrimolabel ?EjemfechaNacia  ?fechaNaciParjeaAfines
    ?ParejaPrimoSegundo ?ParejaPrimoSegundolabel ?ParejaPrimoTercero  ?ParejaPrimoTercero ?ParejaPrimoTercerolabel
    WHERE {
      {
        ?c <http://purl.org/dc/terms/subject>   <http://es.dbpedia.org/resource/Categoría:Casa_de_Austria>.
        ?c rdfs:label ?aLabel.
        service <https://javiermurcia.tech/fuseki/personas-con-hijos/> {
          ?a rdfs:label ?aLabel
          filter (lang (?aLabel) = 'es')
          optional {
            ?a <http://www.wikidata.org/prop/direct/P18> ?pic
          }
          OPTIONAL {
            ?a  <http://www.wikidata.org/prop/direct/P569> ?EjemfechaNacia.
          }
          ?a fami:esParejaDe  ?ParejaPrimo .
          ?a <http://www.relacionesfamiliares/esPrimoDe>  ?ParejaPrimo.
          ?ParejaPrimo   rdfs:label ?ParejaPrimolabel.
          filter (lang (?ParejaPrimolabel) = 'es')
          OPTIONAL {
            ?ParejaPrimo <http://www.wikidata.org/prop/direct/P569> ?fechaNaciParjeaAfines.
          }
          optional {
            ?ParejaPrimo <http://www.wikidata.org/prop/direct/P18> ?pic3
          }
        }
      }
      union {
        ?c <http://purl.org/dc/terms/subject>   <http://es.dbpedia.org/resource/Categoría:Casa_de_Austria>.
        ?c rdfs:label ?aLabel.
        service <https://javiermurcia.tech/fuseki/personas-con-hijos/> {
          ?a rdfs:label ?aLabel
          filter (lang (?aLabel) = 'es')
          optional {
            ?a <http://www.wikidata.org/prop/direct/P18> ?pic
          }
          OPTIONAL {
            ?a <http://www.wikidata.org/prop/direct/P569> ?EjemfechaNacia.
          }
          ?a  fami:esParejaDe ?ParejaPrimoSegundo .
          ?a  <http://www.relacionesfamiliares/esPrimoSegundoDe>  ?ParejaPrimoSegundo.
          ?ParejaPrimoSegundo   rdfs:label ?ParejaPrimoSegundolabel.
          filter (lang (?ParejaPrimoSegundolabel) = 'es')
          OPTIONAL {
            ?ParejaPrimoSegundo <http://www.wikidata.org/prop/direct/P569> ?fechaNaciParjeaAfines.
          }
          optional {
            ?ParejaPrimoSegundo <http://www.wikidata.org/prop/direct/P18> ?pic2
          }
        }
      }
      union {
        ?c <http://purl.org/dc/terms/subject>   <http://es.dbpedia.org/resource/Categoría:Casa_de_Austria>.
        ?c rdfs:label ?aLabel.
        service <https://javiermurcia.tech/fuseki/personas-con-hijos/> {
          ?a rdfs:label ?aLabel
          filter (lang (?aLabel) = 'es')
          optional {
            ?a <http://www.wikidata.org/prop/direct/P18> ?pic
          }
          OPTIONAL {
            ?a  <http://www.wikidata.org/prop/direct/P569> ?EjemfechaNacia.
          }
          ?a fami:esParejaDe ?ParejaPrimoTercero .
          ?a <http://www.relacionesfamiliares/esPrimoTerceroDe>  ?ParejaPrimoTercero.
          ?ParejaPrimoTercero   rdfs:label ?ParejaPrimoTercerolabel.
          filter (lang (?ParejaPrimoTercerolabel) = 'es')
          OPTIONAL {
            ?ParejaPrimoTercero <http://www.wikidata.org/prop/direct/P569> ?fechaNaciParjeaAfines.
          }
          optional {
            ?ParejaPrimoTercero <http://www.wikidata.org/prop/direct/P18> ?pic4
          }
        }
      }
    }group by ?a ?aLabel ?aejempic ?segudoejempic ?primoejempic ?PrimotercerPic ?ParejaPrimo ?ParejaPrimolabel ?EjemfechaNacia ?fechaNaciParjeaAfines
    ?ParejaPrimoSegundo ?ParejaPrimoSegundolabel ?ParejaPrimoTercero ?ParejaPrimoTercerolabel
    LIMIT 100
    Lenguaje del código: PHP (php)

    En este ejemplo combinamos:

    • DBpedia (categorías Wikipedia)
    • Un grafo propio de relaciones familiares

    Detectamos relaciones como:

    • Primos.
    • Primos segundos.
    • Primos terceros.

    Esto demuestra integración semántica real entre datasets.

    Ejecutar consulta en vivo: Abrir demo

    7. Caso avanzado: análisis geoespacial + demografía

    PREFIX monu:  <http://www.monumentos.es/>
    PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
    prefix lugares: <http://www.monumentos.es/lugares/>
    PREFIX owl: <http://www.w3.org/2002/07/owl#>
    PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
    SELECT ?provincia ?provinciaLabel (COUNT (?hospital) as ?Hospitales) (SAMPLE (?Ejempoblación) AS ?población)  ?resultado ?point
    WHERE {
    {
        ?provincia a lugares:Provincia;
                   rdfs:label ?provinciaLabel;
                   <http://www.wikidata.org/prop/direct/P625> ?point.
        optional {
          ?provincia  <http://www.wikidata.org/prop/direct/P1082> ?Ejempoblación
        }
        filter(lang (?provinciaLabel) = 'es')
        ?hospital a lugares:Hospital;
                  <http://www.wikidata.org/prop/direct/P131>  ?municipio.
        ?municipio lugares:Contenida_en_entidades_mayores ?provincia.
        optional {
        ?provincia lugares:Contenida_en_entidades_mayores ?CCAA.
        }
        optional {
          ?CCAA  <http://www.wikidata.org/prop/direct/P1082> ?Ejempoblación
        }
      }
      union {
        ?provincia a lugares:Provincia;
                   rdfs:label ?provinciaLabel;
                   <http://www.wikidata.org/prop/direct/P625> ?point.
        optional {
          ?provincia  <http://www.wikidata.org/prop/direct/P1082> ?Ejempoblación
        }
        filter(lang (?provinciaLabel) = 'es')
        ?hospital a lugares:Hospital;
                  <http://www.wikidata.org/prop/direct/P131>  ?algo.
        ?algo lugares:Está_contenido_en_Municipio ?municipio.
        ?municipio lugares:Esta_contenido_en_Provincia ?provincia.
        optional {
          ?provincia lugares:Contenida_en_entidades_mayores ?CCAA.
        }
        optional {
          ?CCAA  <http://www.wikidata.org/prop/direct/P1082> ?Ejempoblación
        }
      }
      union {
        ?provincia a lugares:Provincia;
                   rdfs:label
    ?provinciaLabel;
                   <http://www.wikidata.org/prop/direct/P625> ?point.
        optional {
          ?provincia  <http://www.wikidata.org/prop/direct/P1082> ?Ejempoblación
        }
        filter(lang (?provinciaLabel) = 'es')
        ?hospital a lugares:Hospital;
                  <http://www.wikidata.org/prop/direct/P131>   ?provincia.
      }
      bind ((?Ejempoblación/100000) as ?resultado)
    }group by ?provincia ?provinciaLabel ?Hospitales ?población  ?resultado ?point
    LIMIT 100Lenguaje del código: PHP (php)

    Calculamos ratios de hospitales por población usando datos geográficos y demográficos.

    Esto es analítica avanzada sobre grafos.

    Ejecutar consulta en vivo: Abrir demo

    Conclusión

    SPARQL no es solo un lenguaje de consulta:

    • Análisis de grafos.
    • Integración de datos.
    • Construcción de conocimiento.
    • Analítica avanzada.

    Su valor real aparece con casos reales, no ejemplos teóricos.

    Sobre mí

    Trabajo en el desarrollo de grafos de conocimiento, integración semántica y análisis de datos RDF.

    Puedes explorar mis demos y sus interfaces de descubrimiento aquí: Ver demos SPARQL

  • Qué son los grafos de conocimiento y por qué son importantes

    Qué son los grafos de conocimiento y por qué son importantes

    Introducción

    Vivimos en una era en la que las organizaciones acumulan enormes cantidades de datos, pero tener datos no es lo mismo que tener conocimiento.

    Aquí es donde entran los grafos de conocimiento: una tecnología capaz de conectar información, revelar relaciones ocultas y permitir nuevas formas de análisis.

    En este artículo explico qué son, cómo funcionan y por qué se están convirtiendo en una pieza clave en inteligencia artificial, análisis de datos y sistemas empresariales. Además, mostraré un ejemplo real basado en un grafo de medicamentos desarrollado a partir de datos públicos.

    ¿Qué es un grafo de conocimiento?

    Un grafo de conocimiento es una estructura que representa información mediante:

    • Entidades (por ejemplo: medicamentos, enfermedades, genes)
    • Relaciones entre esas entidades.

    Por ejemplo:

    “metformina” → trata → “diabetes”

    A diferencia de una base de datos tradicional, donde los datos se organizan en tablas, un grafo permite modelar directamente las relaciones, que es donde reside gran parte del valor.

    ¿En qué se diferencia de una base de datos tradicional?

    Las bases de datos relacionales funcionan bien cuando:

    • Los datos están claramente estructurados.
    • Las consultas son previsibles.

    Pero presentan limitaciones cuando:

    • Las relaciones son complejas.
    • Los datos provienen de múltiples fuentes.
    • Se necesita flexibilidad.

    Los grafos de conocimiento permiten:

    • Integrar datos heterogéneos.
    • Adaptarse a nuevos requisitos.
    • Realizar consultas más cercanas a cómo pensamos.

    ¿Cómo funcionan?

    Los grafos de conocimiento suelen basarse en estándares como:

    • RDF (Resource Description Framework)
    • SPARQL (lenguaje de consulta)
    • OWL (ontologías)

    Estos estándares permiten:

    • Definir entidades de forma unívoca.
    • Establecer relaciones explícitas.
    • Realizar consultas complejas e inferencias.

    Ejemplo real: un grafo de medicamentos

    Para ilustrar estas ideas, he desarrollado un grafo de conocimiento en el ámbito sanitario a partir de datos públicos de la AEMPS.

    🔧 Construcción del grafo

    El proceso incluyó:

    • Transformación de archivos XML y CSV a RDF.
    • Diseño de una ontología específica del dominio.
    • Creación de entidades como:
      • medicamentos
      • principios activos
      • enfermedades
      • interacciones
      • biomarcadores

    Además, se añadieron relaciones que no existían explícitamente en los datos originales, mediante consultas SPARQL e inferencias.

    🔗 Enriquecimiento con datos externos

    Para aumentar el valor del grafo, se realizó una vinculación con fuentes externas:

    • Wikidata (información biológica y médica)
    • DBpedia (contexto adicional)
    • Ontologías biomédicas como ATC o Disease Ontology.

    Esto permitió conectar, por ejemplo:

    • un medicamento → su principio activo
    • el principio activo → enfermedades tratadas
    • las enfermedades → procesos biológicos o genes

    🧠 Descubrimiento de relaciones

    Uno de los puntos clave fue que muchas relaciones no estaban explícitas en los datos originales.

    Mediante consultas e inferencias se pudieron construir:

    • Relaciones entre enfermedades y tratamientos.
    • Interacciones entre principios activos.
    • Conexiones con biomarcadores y genes.

    Esto transforma un conjunto de datos estático en un sistema capaz de generar conocimiento nuevo.

    📊 Resultados

    El grafo resultante incluye:

    • Más de 25.000 medicamentos.
    • Más de 3.000 principios activos.
    • Más de 20.000 enfermedades.
    • Millones de triples RDF.

    Y lo más importante:

    Permite navegar y descubrir relaciones complejas entre todos estos elementos.

    🔍 ¿Qué permite hacer este grafo?

    Por ejemplo:

    • Identificar tratamientos relacionados con una enfermedad.
    • Analizar interacciones entre medicamentos.
    • Explorar conexiones entre fármacos y procesos biológicos.
    • Navegar desde un medicamento hasta genes asociados.

    Este tipo de exploración sería extremadamente compleja con modelos tradicionales.

    ¿Por qué son importantes hoy?

    1. Integración de datos

    Permiten unificar múltiples fuentes en un solo modelo coherente.

    2. Inteligencia Artificial y RAG

    Los grafos de conocimiento son fundamentales para mejorar sistemas de IA:

    • Aportan contexto estructurado.
    • Reducen ambigüedad.
    • Mejoran la calidad de las respuestas.

    3. Descubrimiento de conocimiento

    Permiten identificar relaciones que no eran evidentes:

    • Patrones ocultos.
    • Conexiones indirectas.
    • Inferencias automáticas.

    4. Toma de decisiones

    Transforman datos en conocimiento útil para:

    • Análisis.
    • Planificación.
    • Estrategia.

    Casos de uso

    • Sanidad (medicamentos, enfermedades, genética)
    • Cultura e historia.
    • Sistemas legales.
    • Integración de datos empresariales.

    Conclusión

    Los grafos de conocimiento permiten pasar de:

    👉 datos aislados
    a
    👉 conocimiento conectado

    Y eso cambia completamente cómo entendemos y utilizamos la información.

    Si estás explorando cómo aplicar grafos de conocimiento en tu organización —ya sea para integrar datos, mejorar sistemas de IA o descubrir nuevas relaciones— puedo ayudarte a diseñar la arquitectura, ontologías y procesos necesarios.

  • Por qué tu Inteligencia Artificial necesita leer a Borges

    John Wilkins y la lengua universal

    John Wilkins (14 de febrero de 1614-19 de noviembre de 1672) fue un religioso y naturalista inglés, además del primer secretario de la Royal Society y versátil ensayista.

    Tuvo muy en mente la creación de una lengua franca. Un problema típico de la “República de las letras” donde se alternaba el uso de Latín como lengua de intercambio intelectual y las lenguas vernáculas de cada erudito.

    Desarrolló así la posibilidad de construir un lenguaje mundial artificial, una lengua filosófica, aspecto en el que se insistiría hasta finales del siglo de las Luces. Como desarrollo de esta idea fue autor de la primera lengua sintética («lengua artificial filosófica de uso universal») que dio a conocer en varios de sus libros.

    Y aunque su nombre no ha pasado a los primeros puestos de la historia del pensamiento si que llamó la atención de otro autor muy interesado en el lenguaje, sus juegos y sus límites: el escritor argentino Jorge Luis Borges, que dedicó un ensayo a una de sus obras.

    El Emporio celestial de conocimientos benévolos

    Wilkins proponía un sistema en apariencia muy simple donde dividía el universo en cuarenta categorías divisibles a su vez en especies, asignando a cada género un monosílabo de dos letras; a cada diferencia, una consonante y a cada especie, una vocal.

    Y es en este contexto donde Borges ficciona su celebérrimoEl Emporio celestial de conocimientos benévolos” una cierta enciclopedia china donde los animales se clasificarían en:

    • (a) pertenecientes al Emperador,
    • (b) embalsamados,
    • (c) amaestrados,
    • (d) lechones,
    • (e) sirenas,
    • (f) fabulosos,
    • (g) perros sueltos,
    • (h) incluidos en esta clasificación,
    • (i) que se agitan como locos,
    • (j) innumerables
    • (k) dibujados con un pincel finísimo de pelo de camello,
    • (l) etcétera,
    • (m) que acaban de romper el jarrón,
    • (n) que de lejos parecen moscas.

    A Borges le debió parecer que las las taxonomías poseían una naturaleza arbitraria, ya sea que formen un lenguaje o simplemente compongan una forma de entender y ordenar el mundo. Concluyendo que a su entender no podría haber una clasificación del universo que no fuese arbitraria y llena de conjeturas.

    Dice Borges en dicho relato: «(…) notoriamente no hay clasificación del universo que no sea arbitraria y conjetural. La razón es muy simple: no sabemos qué cosa es el universo».

    Foucault y los límites de nuestro pensamiento

    No mucho tiempo después el filósofo francés Michael Foucault le dedicaría una reflexión en el prefacio de “Las palabras y las cosas”, confesando que leer ese texto de Borges le hizo reír, pero también rompió todas las familiaridades de su pensamiento.

    En efecto esta lista nos hace sonreír por su aparente absurdo e incoherencia lógica desde nuestra perspectiva occidental moderna.

    Pero lo que Foucault nos enseña es que toda clasificación es hija de su tiempo, su cultura y su propósito. Y no existe una forma «natural» u «objetiva» de dividir el mundo en categorías. Lo que a nosotros nos parece lógico (clasificar animales por vertebrados/invertebrados), a otra cultura (o a un sistema con otro propósito) le resultaría inútil.

    El Síndrome de la «Ontología Universal»

    Cuando una empresa u organización decide montar un Grafo de Conocimiento o un sistema RAG para su IA, el primer instinto del equipo técnico es intentar modelar «toda la realidad» de la empresa de forma exhaustiva y perfecta.

    Las posibilidades epistemológicas y de representación que nos ofrecen nuestros datos y el mundo en su conjunto son inagotables, los equipos pueden perder meses discutiendo filosóficamente: «¿Un paciente es una ‘persona’, o es un ‘rol temporal’?», «¿Un contrato es un ‘documento’ o un ‘evento legal’?». Podemos intentar crear una taxonomía universal y acabar con un modelo inmanejable, costoso y que no resuelve nada.

    Ontologías orientadas a propósito

    En Ingeniería Ontológica, cuando diseño, no busco la «Verdad absoluta», sino la «Utilidad operativa». Una ontología solo debe contener los conceptos y relaciones estrictamente necesarios para responder a las preguntas de negocio que la organización necesita resolver.

    Una ontología debe diseñarse teniendo en cuenta:

    • Los objetivos del sistema.
    • Los tipos de consultas que se quieren realizar.
    • Los procesos que debe soportar.
    • Las relaciones que se quieren descubrir.
    • Las inferencias que se esperan conseguir.

    Por ejemplo, un sistema sanitario puede organizar medicamentos según:

    • Principios activos.
    • Indicaciones terapéuticas.
    • Regulación.
    • Interacciones.

    Cada enfoque produce un modelo diferente.

    Los grafos permiten:

    • Múltiples relaciones simultáneas.
    • Diferentes perspectivas sobre las mismas entidades
    • Extender el modelo sin romper la estructura.

    Conclusiones

    La clasificación de Borges parece absurda porque no compartimos su sistema de referencia.

    Pero nos recuerda algo importante:

    Toda taxonomía es una forma de ordenar el mundo según ciertos criterios.


    Cuando una organización diseña una ontología o un grafo de conocimiento debería preguntarse:

    • Qué preguntas quiere poder responder
    • Qué relaciones son relevantes.
    • Qué decisiones necesita apoyar.

    Solo entonces la clasificación deja de ser arbitraria y se convierte en una herramienta para generar conocimiento.

    Y en ingeniería del conocimiento esos criterios deben ser explícitos y conscientes.

    La belleza y potencia de la Web Semántica (RDF/OWL) es su flexibilidad. Permite que diferentes departamentos tengan «vistas» distintas del mismo mundo, integradas en un solo grafo.

    Diseñar la arquitectura de datos de una organización requiere tanto de rigor técnico como de visión filosófica para entender el negocio. Si tu empresa está luchando por conectar sus silos de información sin perderse en el intento de cartografiar el universo entero, hablemos.