Notificaciones de datos vinculados

Las Notificaciones de Datos Enlazados ( LDN ) ^{[ 3 ]} son ​​una recomendación del W3C que describe un protocolo de comunicación basado en HTTP , URI y RDF sobre cómo los servidores ( receptores ) pueden recibir mensajes enviados por aplicaciones ( remitentes ), así como cómo otras aplicaciones ( consumidores ) pueden recuperar esos mensajes. Cualquier recurso web (como una página HTML ) puede anunciar un punto final de recepción ( bandeja de entrada ) para mensajes de notificación. Los mensajes se expresan en RDF y pueden contener datos arbitrarios.

La web es un sistema descentralizado de recursos web, publicados por múltiples organizaciones e individuos. Los recursos web, como las páginas web y los datos enlazados con una estructura más formal , suelen incluir enlaces a otros recursos en la web y pueden comentarlos o describirlos de diversas maneras. Sin embargo, quienes reciben dichos enlaces generalmente no son notificados de su creación y, por lo tanto, no pueden proporcionar enlaces inversos sin intervención manual. Las interacciones dentro de las plataformas de redes sociales , como los comentarios en un artículo de noticias, actualmente están "bloqueadas" dentro de la plataforma y son difíciles de acceder desde el resto de la web.

Existen varios mecanismos de retroalimentación que se utilizan habitualmente entre sistemas de blogs ; por ejemplo, una respuesta en el blog B a una publicación en el blog A provoca que la plataforma de B envíe un pingback para que se muestre en el blog original A. Sin embargo, estos mecanismos suelen tener limitaciones en cuanto a la información estructurada que se puede enviar, y las notificaciones en sí mismas no forman parte de la web descentralizada y pueden ser difíciles de consumir por cualquier aplicación de terceros.

Una motivación clave para LDN es brindar soporte a las notificaciones entre aplicaciones web descentralizadas, ^{[ 4 ]} incluyendo navegadores web que, al no tener su propio servidor HTTP, no pueden generar un enlace HTTP para sus mensajes de respuesta. Otra motivación es estructurar las notificaciones como declaraciones RDF utilizando cualquier vocabulario controlado , de modo que cualquier aplicación receptora pueda seleccionar la información específica que comprende.

• Un remitente o receptor realiza una GETsolicitud HEADa un recurso HTTP existente. Su URI de bandeja de entrada se descubre a partir de:
  • Una Link:relación en los encabezados de respuesta HTTP de tipohttp://www.w3.org/ns/ldp#inbox
  • Una declaración RDF incrustada en el cuerpo HTTP usando la propiedad RDF.http://www.w3.org/ns/ldp#inbox
• Un remitente crea una nueva notificación (por ejemplo, como JSON-LD ), que envía POSTa la URI de la bandeja de entrada .
  • El receptor crea un nuevo recurso HTTP que contiene la notificación enviada y responde con 201 Createdla URI creada.
• Un consumidor recupera RDF del URI de la bandeja de entrada descubierta usando GET, luego:
  • El consumidor analiza el cuerpo de la respuesta para encontrar declaraciones RDF con la propiedad http://www.w3.org/ns/ldp#contains. El objeto de estas declaraciones proporciona las URI a las notificaciones LDN aceptadas.
  • El consumidor recupera cualquiera de las notificaciones vinculadas GETy procesa su RDF de una manera específica para la aplicación.
  • Las notificaciones siguen estando accesibles y, por lo tanto, se pueden enlazar y describir en otros recursos web.

En cada etapa, el remitente y el consumidor pueden realizar una negociación de contenido para enviar o recibir en cualquier formato de serialización RDF acordado mutuamente , pero un receptor LDN compatible debe admitir al menos JSON-LD .

Un remitente o consumidor descubre la bandeja de entrada para una URI determinada, en este ejemplo utilizando el HEADmétodo:

HEAD https://example.org/article/5 HTTP / 1.1

HTTP / 1.1 200 OK Enlace : <https://example.org/inbox/7>; rel="http://www.w3.org/ns/ldp#inbox"

Un remitente envía una notificación a la bandeja de entrada detectada, en este ejemplo utilizando el vocabulario Schema.org :

POST https://example.org/inbox/7 HTTP / 1.1 Content-Type : application/ld+json{ "@context" : "http://schema.org" , "@type" : "ReviewAction" , "object" : { "@id" : "https://example.org/article/5" }, "agent" : { "@type" : "Person" , "name" : "Alice" }, "result" : { "@type" : "Review" , "reviewBody" : "¡Este artículo es el mejor que he visto!" } }

HTTP / 1.1 201 Created Location : http://example.org/inbox/f44f3f11

Un consumidor enumera el contenido de la bandeja de entrada descubierta y encuentra 3 notificaciones:

GET https://example.org/inbox/7 HTTP / 1.1 Content-Type : application/ld+json

HTTP / 1.1 200 OK Content-Type : application/ld+json{ "@context" : "http://www.w3.org/ns/ldp" , "@id" : "https://example.org/inbox/7" , "contains" : [ "https://example.org/inbox/5c6ca040" , "https://cdn.example.org/inbox/92d72f00" , "https://example.org/inbox/f44f3f11" , ] }

Tenga en cuenta que las URI del recurso original, la bandeja de entrada y las notificaciones no tienen por qué estar alojadas en el mismo servidor HTTP (por ejemplo, pueden estar en una CDN ). El usuario sigue los enlaces para acceder a las notificaciones que desee consultar.

En este ejemplo, el consumidor recupera la nueva f44f3f11notificación, con negociación de contenido para dar preferencia al formato Turtle RDF:

GET https://example.org/inbox/f44f3f11 HTTP / 1.1 Accept : application/ld+json;q=0.9, text/turtle;q=1.5

HTTP / 1.1 200 OK Content-Type : text/turtle@prefix esquema: <http://schema.org/> . [ un esquema : ReviewAction ; esquema : agente [ un esquema : Persona ; esquema : nombre "Alice" ]; esquema : objeto <https://example.org/article/5> ; esquema : resultado [ un esquema : Revisión ; esquema : cuerpo de la revisión "¡Este artículo es el mejor que he visto!" ] ] .

Existen varias implementaciones de LDN , ^{[ 4 ] [ 5 ]} que abarcan emisores, consumidores y receptores, incluyendo:

• dokieli (remitente, consumidor)
• errol (remitente)
• Fedora Commons (receptor)
• Apache Marmotta (receptor)
• LDP de carbono (receptor)
• Reglas de edición vinculadas (remitente)
• Sólido (emisor, receptor, consumidor)
• Servidor universal Virtuoso (receptor, consumidor)

Cualquier implementación de Linked Data Platform (LDP) también es un receptor de notificaciones de Linked Data conforme , ya que LDN es un subconjunto estricto de LDP. ^{[ 4 ]}