Knowledge graphs y Modelos de Datos
Conforme las aplicaciones semánticas incrementan en popularidad, cada vez más personas se preguntan la diferencia entre una ontología y un knowledge graph (¿o una?), y la importancia de entender estos conceptos para estrategias de posicionamiento web (SEO) y content marketing.
En este artículo mostraré que son los ontologías y los knowledge graphs enfocando en sus diferencias y cómo trabajan en conjunto para organizar grandes volúmenes de datos e información. Finalmente, cuál es la importancia de todo esto para nuestras estrategias de adquisición orgánica.
¿Qué es una ontología?
Una ontología es un modelo de datos semántico que define los tipos de cosas que existen dentro de nuestro dominio y las propiedades que pueden utilizarse para describirlas. Las ontologías son por lo tanto modelos de datos generalizados que solo modelan tipologías de cosas generales que comparten ciertas propiedades; no incluyen información especifica sobre cosas individuales en nuestro dominio.
Por ejemplo, en lugar de describir a Bigotes, tu gato 🐱, y todas sus características individuales, una ontología debe enfocarse en describir los conceptos generales de los gatos, capturando características que todos o la mayoría de gatos puedan llegar a tener.
Esto nos permitirá describir a un mayor volumen de gatos en el futuro.
Las ontologías se dividen principalmente en 3 componentes:
- Clases: los diferentes tipos de cosas que existen en nuestros datos.
- Relaciones: propiedades que conectan a dos clases.
- Atributos: propiedades que describen una clase individual.
Por ejemplo, imaginemos que tenemos la siguiente información sobre libros:
| Libros | ||||
|---|---|---|---|---|
| Titulo | Autor | Casa Editorial | Año | Secuela |
| Sapiens | Yuval Noah Harari | Penguin Random House | 2011 | 21 Lessons for the 21st Century |
| 21 Lessons for the 21st Century | Yuval Noah Harari | Penguin Random House; Hachette | 2018 | Homo Deus |
| Zero to One | Peter Thiel | Crown Business | 2014 |
|
| Don’t make me think (Revisited) | Steve Krug | New Riders; HarperCollins | 2014 |
|
| Casa Editorial | ||
|---|---|---|
| Nombre | Ciudad | País |
| Penguin Random House | London | Reino Unido |
| Crown Business | Nueva York | USA |
| New Riders | San Francisco | USA |
| Hachette | Nueva York | USA |
| HarperCollins Publishers Australia | Pymble | Australia |
| Autores | |
|---|---|
| Nombre | País de nacimiento |
| Yuval Noah Harari | Israel |
| Peter Thiel | Alemania |
| Steve Krug | USA |
Primero debemos identificar nuestras clases (las cosas únicas que hay en nuestro set de datos). Nuestro datos de ejemplo capturan información sobre libros, por lo que ese es nuestro primer candidato a una clase.
Particularmente este ejemplo describe cierto tipo de cosas sobre los libros, cómo Casas Editoriales y Autores. Continuando el análisis podemos ver que nuestros datos también describen información sobre estas Casas Editoriales y Autores, como su ubicación.
Esto nos deja con 4 clases para este ejemplo:
- Libros
- Autores
- Casas Editoriales
- Ubicaciones
Luego tenemos que identificar relaciones y atributos (para hacerlo más simple podemos considerar en esta ocasión tanto las relaciones como los atributos como propiedades). Utilizando las clases que desarrollamos podemos ver los datos de nuestro ejemplo e identificar todas las propiedades que vemos para cada clase.
Por ejemplo para la clase libros algunas propiedades que resaltan son:
- Los libros tienen autores.
- Los libros tienen casas editoriales.
- Los libros son publicado en un determinado tiempo (año).
- Los libros son seguidos por secuelas (otros libros).
Algunas de estas propiedades son relaciones que de hecho conectan a dos de nuestras clases. Por ejemplo, la propiedad “los libros tienen autores” es una relación que conecta a nuestras clases de autores y libros.
Otras propiedades como “los libros son publicados en un determinado tiempo (año)”, son atributos, por que describen una característica de una clase, y no una relación entre dos clases. 🤯
Es importante considerar que estas propiedades pueden aplicar a cualquier libro, pero no necesariamente tienen que aplicar a todos los libros. Un claro ejemplo es que no todos los libros tiene secuelas.
Esto esta bien para nuestro ejemplo ya que queremos identificar propiedades que puedan aplicar a la mayoría, pero no a todos los libros.
Aunque el set de datos sea fácil de leer e interpretar lógicamente, siempre es recomendable re escribir de forma linear estas propiedades para identificar claramente nuestras clases y propiedades. Por ejemplo:
- Libro —> tiene autor —> Autor
Como puedes imaginar hay muchas posibles combinaciones que identificar, para hacerlo más sencillo nos concentraremos en las siguientes:
- Libro —> tiene autor —> Autor
- Libro —> tienes casa editorial —> Casa Editorial
- Libro —> fue publicado en —> Año de publicación
- Libro —> es seguido de —> Libro
- Autor —> trabaja con —> Casa Editorial
- Casa Editorial —> esta ubicado en —> Ubicación
- Ubicación —> esta ubicado en —> Ubicación
Recuerda que nuestra ontología es un modelo de datos generales, por lo que no queremos incluir información especifica de un libro. Queremos crear una arquitectura re usable para describir libros en el futuro.
Al tener todo analizado y estructurado, podemos combinar nuestras clases y relaciones en un gráfico de relaciones (ya vemos hacia dónde va el tema, ¿no?):
¿Qué es un Knowledge Graph?
Usando nuestra ontología anterior como marco de trabajo, podemos añadir datos reales sobre libros, autores, casas editoriales y ubicaciones de forma individual para crear un knowledge graph. Con la información de las tablas de datos anteriores y nuestra ontología, podemos crear instancias especificas para cada una de nuestras relaciones ontológicas.
Por ejemplo si tenemos una relación entre Libros —> tiene autor —> Autor en nuestra ontología, una instancia individual de esta relación se vería así:
Si añadimos la información individual que tenemos de uno de los libros, por ejemplo, Sapiens, podemos empezar a visualizar el inicio de nuestro Knowledge Graph:
Si aplicamos nuestra ontología al resto de datos en las tablas anteriores, obtendremos un Knowledge Graph que nos permitirá visualizar la información como una red de relaciones inter conectadas, en lugar de datos individuales, lo que nos permitirá comprender nuevas relaciones entre los puntos de información que no podríamos visualizar de otra manera.
Conclusión
¿Cuál es la diferencia entre una ontología y un Knowledge Graph?
Cómo podemos concluir de los ejemplos anteriores, un knowledge graph es creado cuando aplicas cierta ontología (nuestro modelo de datos) a un conjunto de datos individuales (libros, autores, editoriales). En otra palabras:
Ontología + datos individuales = knowledge graph
¿Por qué es importante entender cómo se estructura un Knowledge Graph?
Si estas en el mundo del posicionamiento web, sabes que The Knowledge Graph de Google (TKG) fue introducido en 2012 con el objetivo de brindar a los usuarios resultados útiles y relevantes utilizando técnicas de búsqueda semántica.
TKG utiliza las relaciones entre palabras y conceptos para entender el contexto de un término de búsqueda, por lo que podemos ayudar a Google a entender mejor nuestro contenido si entendemos cómo lo visualiza y estructura, y aplicando ciertas buenas prácticas en nuestra web como:
- HTML5 Semántico (incluye el uso de headings!)
- Estructurando nuestro contenido utilizando tablas correctamente identificadas.
- Utilizando inteligentemente semantic triples en nuestro copy. (artículo próximamente)
- Y por supuesto, implementando muchos datos estructurados. 🤴🏻
¿Qué más sabes sobre The Knowledge Graph de Google? ¿Tienes más dudas sobre cómo estructurar un ontología? ¡Comenta!