Header Ads Widget

Ticker

6/recent/ticker-posts

Uso de JSON-LD para establecer datos enlazados semánticos


 La web mundial es una herramienta poderosa, y gran parte de este poder proviene de las intersecciones relacionales entre las páginas web, los datos que albergan estas páginas y sus relaciones posteriores con otras páginas web y conjuntos de datos. De hecho, es esta relación fundamental la que impulsa el modelo conceptual y el enfoque de la red mundial : sin estas relaciones, no habría Reddit, ni BBC News, y ciertamente no habría Wikipedia.

JSON-LD-logo-64

A pesar del éxito de este marco, todavía existen algunos problemas dentro del contexto más amplio de la red mundial. Uno de estos problemas principales es cerrar la brecha entre la interacción humana y la interacción de la máquina a través de datos vinculados . Hoy, veremos una solución a este problema conocida como JSON-LD . Veremos de dónde proviene el problema mencionado anteriormente, qué significa fundamentalmente para los proveedores web y cómo JSON-LD está preparado como una solución en este espacio.

La cuestión fundamental

Para comprender el valor de JSON-LD , debemos echar un vistazo al problema fundamental que está tratando de resolver. Cuando los usuarios promedio utilizan la World Wide Web , tienden a dar por sentadas muchas de sus relaciones y opciones de diseño: el vínculo interrelación entre varios sitios web y los datos que alojan esos sitios se considera una tecnología "establecida", una que se planifica fundamentalmente y completado. La verdad del asunto es que esto no podría estar más lejos de la verdad.

Los datos en la web pertenecen a una amplia variedad de tipos de contenido , que van desde video hasta audio, desde texto plano hasta renderizado dinámico. Si bien esto ciertamente brinda a los usuarios una experiencia multimedia, es la vinculación de un sitio web a otro, proporcionando datos relacionados con los que consumió anteriormente, lo que lleva esta interacción de una experiencia multimedia a una rica experiencia multimedia . Esta vinculación de recursos es donde la "red mundial" recibe su nombre: el contenido se forma a partir de páginas simples de un solo servicio en redes complejas de datos.

El problema es que este sistema está diseñado para humanos . Si bien esto puede parecer un problema extraño, uno debe recordar que todos estos datos nos son proporcionados por máquinas y, como tal, la vinculación relacional y el contenido detectable orientado al uso humano dan como resultado un sistema en el que los usuarios experimentan medios que no pueden ser adecuadamente contextualizado por máquinas. En otras palabras, una máquina sabe que hay contenido y una máquina sabe que hay vínculos entre el contenido, pero exactamente cómo se vinculan un video de "John F. Kennedy" y un artículo sobre "La Guerra Fría" es casi en su totalidad perdido a una máquina.

Se han hecho algunos avances para rectificar esto, pero todos son esencialmente descomposiciones del contenido web en fragmentos que se contextualizan más fácilmente utilizando sistemas adicionales. El sistema de etiquetado en WordPress o las categorías que se encuentran en MediaWiki son semi-efectivos para resolver estos problemas, pero nuevamente, requieren un gran esfuerzo por parte del usuario y son esencialmente una solución centrada en el ser humano para un problema centrado en la máquina.

Datos vinculados

Con todo esto en mente, se puede encontrar una solución en el concepto de Datos Vinculados . Acuñado por Tim Berners-Lee , el inventor de la World Wide Web, el concepto es simple: vincular datos de tal manera que se asegure que las máquinas tengan la capacidad no solo de reconocer vínculos entre datos, sino de contextualizarlos y comprenderlos . En su nota de 2006 sobre datos vinculados , Berners-Lee presenta cuatro principios básicos para el establecimiento de dichos datos vinculados:

  • Utilice URI para nombrar e identificar contenido;
  • Utilice HTTP URI para que se puedan buscar estas entidades de contenido identificadas y con nombre;
  • Utilice estándares abiertos como RDF o SPARQL para proporcionar información útil sobre lo que identifica un nombre a quienes consultan el contenido; y
    Cuando publique datos en la web, refiérase a estas cosas por sus nombres basados ​​en HTTP URI.

El concepto completo es crear una red de datos que se nombra de tal manera que la red se puede consultar y que, cuando se consulta, esta red puede proporcionar datos adicionales en un formato estandarizado. Luego, estos datos se pueden usar para inferir más relaciones, obtener más datos y crear una red semántica más poderosa.

Como ejemplo de lo que aboga Berners-Lee, imaginemos una visita teórica al sitio web de las API nórdicas de un gerente, "Michael". Michael está suscrito a las API nórdicas y, al encontrar un artículo útil, decide enviarlo por correo electrónico a un compañero de trabajo de otra oficina, Jens. Jens ve el artículo y lo comenta.

De acuerdo con el paradigma de diseño clásico, todo lo que ha ocurrido aquí es una transferencia de datos; si bien hay una relación detallada entre Michael y Jens, no hay influencia de esto, y en lo que respecta a las entidades, esta relación también podría no ser existe.

Ahora veámoslo desde una perspectiva de datos enlazados . En esta situación, Michael y Jens utilizan una plataforma social para sus esfuerzos internos. Michael usa el botón de la plataforma social para compartir este artículo, etiquetando a Jens en el comentario. Jens recibe la notificación de que han sido vinculados y comenta sobre el artículo.

En el nivel básico, este parece ser exactamente el mismo intercambio, pero en realidad, hay mucho valor oculto debajo. Cuando se representa correctamente mediante rutas de URI (generadas a través de botones para compartir, sistemas de perfiles para comentar, etc.), cada entidad en este intercambio expone una cantidad impresionante de datos relacionales. En un escenario de datos vinculados, así es como se ve el intercambio:

Estas relaciones son importantes. Al definir a Michael como suscriptor de las API nórdicas, a Jens como comentarista de este artículo y a Michael y Jens como compañeros de trabajo a través de un enlace social, creamos una red de contenido interrelacionado con un contexto directo y real que las máquinas que manejan pueden entender datos.

Un enlace incrustado en la plataforma social de Michael que luego es comentado por Jens crea una diferencia fundamental en cómo una máquina entiende este comportamiento; anteriormente, una máquina solo sabía que existe un artículo, que hay un suscriptor y que hay un comentario. Con Linked Data, el sistema sabe todo esto, pero también conoce el camino exacto que tomaron estos datos, cómo el comentario está vinculado al enlace compartido de Michael, la relación entre Jens y Michael y las complejidades de dicha relación entre las tres entidades.

Berners-Lee resume mejor este tipo de red durante una charla TED sobre el concepto:

“Si tomo uno de estos nombres HTTP y lo busco… obtendré algunos datos en un formato estándar que son datos útiles que a alguien le gustaría saber sobre esa cosa, sobre ese evento […] Cuando obtengo De vuelta esa información, no se trata solo de la altura y el peso de una persona y cuando nació, tiene relaciones. Y cuando tiene relaciones, siempre que expresa una relación, la otra cosa con la que está relacionada recibe uno de esos nombres que comienzan con HTTP ".

Propuesta de valor para API web

Todo esto es increíblemente importante para las API web por una variedad de razones. En primer lugar, pasar a datos vinculados obliga a los proveedores a hacer que los datos sean más "utilizables": al proporcionar más información a otros proveedores, las API web pueden formar una red mucho más poderosa de lo que pueden esperar por sí mismos.

Problemas con los datos vinculados

Desafortunadamente, la implementación de Linked Data trae consigo sus propios problemas. Estos se pueden resumir ampliamente en dos puntos.

Primero, la web admite una amplia gama de formatos y sistemas. Para respaldar relaciones significativas, estos formatos deben estar estandarizados o con un amplio respaldo, y cualquiera de las partes crea problemas adicionales. Si exige un formato específico, está excluyendo usos posiblemente poderosos para esos otros formatos, y si permite que se use cualquier formato, crea una segmentación en apoyo.

En segundo lugar, se debe considerar la naturaleza fundamental en la que se vinculan estos datos para establecer estas relaciones. El simple hecho de vincular el contenido directamente no crea una relación: el hecho de que Jens exista en el servidor de las API nórdicas no le dice nada sobre la relación, y simplemente sirve como un camino de un solo sentido. Por lo tanto, los sistemas deben utilizar datos vinculados como un enfoque predeterminado para participar y aprovechar el poder de una red de relaciones semánticas de este tipo y, como tal, también deben vincularse a la consideración de los formatos .http://internalwiki.com/Jens

Lea también: Tipos de hipermedia para API web

JSON-LD

Ingrese JSON-LD. Basado en los conceptos expuestos anteriormente, JSON-LD es un formato de datos vinculados que está diseñado sobre el JSON de gran éxito y casi omnipresente. Al utilizar datos JSON, JSON-LD busca establecer los datos semánticos muy relacionales que hemos estado discutiendo hasta ahora.

La forma en que JSON-LD establece estas relaciones es realmente bastante simple. Volvamos a nuestro ejemplo, donde Michael comparte un sitio con Jens. En un diseño tradicional, simplemente tendríamos un pequeño rango de entradas de datos, generalmente el sitio en el que se originó un usuario, algunos datos métricos para su navegador, IP, etc., y posiblemente una referencia para cuando se comparte el artículo. Si bien esto es ciertamente útil para los humanos, no hace nada por las máquinas.

En cambio, lo que podemos hacer es asignar a estos usuarios algunos datos básicos en JSON-LD que establecen una relación que luego puede ser inferida o establecida por los servidores que intercambian estos datos. Echemos un vistazo a una entrada JSON-LD para Michael:

{
  "@context": "http://organization.org/context/userjsonld",
  "@id": "http://organization.org/managers/denver/michael",
  "name": "Michael",
  "position": "Manager",
  "department": "http://organization.org/departments/design"
  “location”: “Denver”
}

Entonces, ¿qué nos dice esta entrada específicamente? En primer lugar, al definir @context@iden nuestra entrada JSON-LD, establecemos un marco mediante el cual se deben interpretar estos datos. Michael es parte de una corporación conocida como "Organización", y tanto su URI como su entrada de "ubicación" nos dicen que tiene su sede en Denver. Su URI además nos dice que él es un gerente, y esta posición luego se indica explícitamente por el valor de "posición". Además, definimos el departamento para el que es gerente.

Es posible que estos datos no parezcan útiles tal como están, pero creemos una entrada JSON-LD para Jens.

{
  "@context": "http://organization.org/context/userjsonld",
  "@id": "http://organization.org/employees/remote/jens",
  "name": "Jens",
  "position": "Designer",
  "department": "http://organization.org/departments/design"
  “location”: “Remote”
}

Ahora hemos establecido una entrada para Jens. Tenga en cuenta que tanto el identificador URI como el valor de "ubicación" indican dónde trabaja Jens, como empleado remoto. Independientemente, Jens está establecido para trabajar como empleado remoto en el mismo departamento que Michael y, por lo tanto, podemos inferir una relación subordinada.

Cuando estos datos se envían al sitio web de las API nórdicas, suceden algunas cosas que antes no ocurrían. Debido a que las API nórdicas ya tienen una entrada para Michael que apunta a esta misma entrada, tenemos un punto de referencia desde el cual interpretar todos los demás datos. Sin la entrada de Michael, si recibiéramos la entrada de Jens, no tendríamos información alguna sobre cómo están relacionados, pero como tenemos los datos, cuando recibimos la información de Jens, tenemos puntos de referencia para la organización, para el puesto. , y por la relación entre estas entradas.

De esta manera, no solo podemos documentar una relación entre estas dos entradas que de otro modo no estarían relacionadas, podemos comenzar a explorar relaciones más extensas. Digamos por un momento que las API nórdicas tienen una base de conocimientos de organizaciones con las que están asociadas, y que Michael es un gerente destacado.

Cuando se crea un artículo sobre Michael y su trabajo, una entrada de datos vinculados puede ayudar a contextualizar proyectos, como vincular automáticamente perfiles sociales, vincular cuentas de GitHub e incluso crear bases de datos internas sobre la efectividad de una campaña publicitaria solicitada por Michael entre los suscriptores registrados. .

De esta manera, Linked Data, y más específicamente JSON-LD, es una herramienta muy poderosa para crear relaciones y definir contexto.

Fortalezas de JSON-LD

JSON-LD es una solución muy sólida para muchos usuarios debido a un hecho simple: elimina la ambigüedad . Considere nuestras entradas JSON-LD anteriores: notamos específicamente un @contexttipo de datos. ¿Qué es eso? En pocas palabras, es un esquema que define lo que significan nuestros términos.

Debemos recordar que esta comunicación de datos se realiza entre diferentes sitios. Debido a esto, no todos los términos se definirán exactamente de la misma manera, mientras que "nombre" podría significar el nombre en Facebook, "nombre" en LiveJournal podría ser su nombre de usuario o su alias.

Como tal, poder definir el esquema con el que estamos operando y luego comparar esos términos con otro esquema durante el intercambio de datos elimina una gran cantidad de ambigüedad. Esto, a su vez, hace que los datos sean más útiles, más completos y mejor relacionados.

Además, JSON-LD aprovecha estas especificaciones de tipo con gran efecto en @id@vocab@type, y más - ser capaz de definir elementos específicos de sus paquetes de datos significan que el usuario puede definir qué datos medios sin tener que definir específicamente una aceptación forzada común de estándar - algo que la estandarización, aunque efectiva, tiende a ser suficiente. Ser capaz de saltarse este enfoque de “estandarización forzada” lo convierte en una solución muy poderosa.

Debilidad de JSON-LD

Se puede argumentar que JSON-LD no es la solución perfecta. Primero, JSON puede ser difícil de analizar para humanos y, a veces, más difícil de escribir. JSON-LD tiene un sistema de escritura muy poderoso, pero esto también significa que es más complejo de utilizar que algo como HAL. Si se tuviera que identificar un solo competidor, de hecho, sería absolutamente HAL, y muchos de sus puntos de venta parecen estar dispuestos a explotar los problemas inherentes a JSON-LD.

HAL es simple y utiliza un sistema muy simple y fácil de entender, dos cosas que JSON-LD, en su forma más compleja, no lo son. Como parte de esto, muchos han acusado a JSON-LD de “ reinventar la rueda ”, especialmente cuando se trata del uso evolutivo de tipos definidos. Para muchas personas, parece ser una simple reutilización de la verborrea ya existente en un entorno más complejo.

Sin embargo, eso no quiere decir que JSON-LD sea más complejo y algo derivado sea necesariamente algo malo, como Manu Sporny, uno de los principales editores y creadores de la especificación JSON-LD, dijo con tanta elocuencia:

“Lo más simple no siempre es bueno. En los casos enumerados anteriormente, más simple significaba que HAL no era capaz de abordar los casos de uso anteriores. Debe utilizar la solución más simple que aborde su caso de uso hoy y en el futuro. Si HAL es eso, use HAL. Si JSON-LD es esa solución, úsela ".
Fuente

Conclusión

El argumento más fuerte para JSON-LD es en realidad uno de autoridad: W3C está en proceso de convertir JSON-LD en una especificación estándar . El simple hecho es que JSON-LD, aunque puede tener sus problemas, ha sido diseñado desde cero para resolver un problema fundamental y se basa en un concepto definido por el creador de la World Wide Web.

Si bien podemos discutir sobre la eficiencia y el enfoque específico durante el resto del tiempo, tener una solución basada en un concepto del creador de la red mundial e incorporada al W3C después de una revisión exhaustiva de algunos de los principales expertos en el campo ciertamente hace que no adopción un argumento difícil de aceptar.

¿Qué piensa sobre JSON-LD y el proceso de convertirlo en una especificación estándar? ¿Crees que existen mejores soluciones? Háganos saber en la sección de comentarios a continuación.

Publicar un comentario

0 Comentarios