Уведомления о связанных данных - Linked Data Notifications

Уведомления о связанных данных (LDN) ^[1] это W3C Рекомендация это описывает протокол связи на основе HTTP, URI, и RDF на том, как серверы (приемники) могут получать сообщения, отправленные им приложениями (отправители), а также как другие приложения (потребители) может получить эти сообщения. Любой веб-ресурс (например, HTML страница) может рекламировать принимающую конечную точку (почтовый ящик) для уведомлений. Сообщения выражаются в RDF и могут содержать произвольные данные.

Мотивация

В сеть это децентрализованная система веб-ресурсов, публикуемых множеством организаций и частных лиц. Веб-ресурсы, такие как веб-страницы и более формально структурированные Связанные данные, часто включают ссылки на другие ресурсы в Интернете и могут комментировать или описывать их различными способами. Однако получающая сторона, как правило, не уведомляется о создании такой ссылки и, следовательно, не может предоставить обратные ссылки без ручного вмешательства. Взаимодействие внутри социальные медиа платформы, такие как комментарии к новостной статье, в настоящее время «заблокированы» внутри платформы и труднодоступны через Интернет.

Несколько обратная ссылка механизмы существуют и обычно используются между системы блогов, например "ответный" пост в блоге B о сообщении в блоге A заставляет платформу B отправлять пингбэк должны быть показаны в исходном блоге A. Однако эти механизмы обычно ограничены в том, что структурированная информация может быть отправлена, а сами уведомления не являются частью децентрализованной сети и могут быть трудны для использования любым сторонним приложением.

Ключевой мотивацией для LDN является поддержка уведомлений между децентрализованными веб-приложениями,^[2] включая веб-браузеры, которые - не имея собственного HTTP-сервера - не могут генерировать HTTP-ссылку для своих ответных сообщений. Еще одна мотивация - структурировать уведомления в виде операторов RDF с использованием любых Контролируемый словарный запас - чтобы любое приложение-потребитель могло выбрать конкретную информацию, которую они понимают.

Протокол

• А отправитель или же приемник выполняет ПОЛУЧАТЬ или же ГОЛОВА к существующему ресурсу HTTP. Его почтовый ящик URI обнаруживается либо из:
  • А Связь: отношение в заголовках HTTP-ответа типа http://www.w3.org/ns/ldp#inbox
  • Заявление RDF, встроенное в тело HTTP с помощью свойства RDF http://www.w3.org/ns/ldp#inbox
• А отправитель создает новое уведомление (например, как JSON-LD ), который ПОЧТОВЫЙс к почтовый ящик URI.
  • В приемник создает новый HTTP-ресурс, содержащий опубликованное уведомление, и отвечает 201 Создано и созданный URI.
• А потребитель извлекает RDF из обнаруженного почтовый ящик URI с использованием ПОЛУЧАТЬ, тогда:
  • В потребитель анализирует тело ответа, чтобы найти операторы RDF со свойством http://www.w3.org/ns/ldp#contains. Объект этих операторов предоставляет URI для принятых уведомлений LDN.
  • В потребитель получить любое из связанных уведомлений, используя ПОЛУЧАТЬ и обрабатывают их RDF в зависимости от приложения.
  • Уведомления остаются доступными и, следовательно, могут быть связаны с другими веб-ресурсами и описаны в них.

На каждом этапе отправитель и потребитель могут выполнять согласование содержания отправлять или получать в любых взаимно согласованных RDF формат сериализации, однако совместимый приемник LDN должен поддерживать как минимум JSON-LD.

Примеры

А отправитель или же потребитель обнаруживает почтовый ящик для данного URI, в этом примере используя ГОЛОВА метод:

ГОЛОВА https://example.org/article/5 HTTP/1.1

HTTP/1.1 200 OkСвязь: ; rel = "http://www.w3.org/ns/ldp#inbox"

А отправитель отправляет уведомление в обнаруженный почтовый ящик, в этом примере с помощью Schema.org словарный запас:

ПОЧТОВЫЙ https://example.org/inbox/7 HTTP/1.1Тип содержимого: приложение / LD + JSON{ "@context": "http://schema.org",  "@тип": "ReviewAction",  "объект" : {    "@я бы": "https://example.org/article/5"  },  "агент": {     "@тип": "Человек",    "имя": "Алиса"   },  "результат": {    "@тип": "Рассмотрение",    "reviewBody": "Эта статья - лучшая, что я когда-либо видел!"  }}

HTTP/1.1 201 СозданныйМесто расположения: http://example.org/inbox/f44f3f11

А потребитель перечисляет содержимое обнаруженного почтового ящика, чтобы найти 3 уведомления:

ПОЛУЧАТЬ https://example.org/inbox/7 HTTP/1.1Тип содержимого: приложение / LD + JSON

HTTP/1.1 200 OkТип содержимого: приложение / LD + JSON{  "@context": "http://www.w3.org/ns/ldp",  "@я бы": "https://example.org/inbox/7",  "содержит": [    "https://example.org/inbox/5c6ca040",    "https://cdn.example.org/inbox/92d72f00",    "https://example.org/inbox/f44f3f11",  ]}

Обратите внимание, что URI исходного ресурса, почтового ящика и уведомлений не обязательно должны размещаться на одном HTTP-сервере (например, они могут быть на CDN ). В потребитель переходит по ссылкам для любых уведомлений, которые они хотят получить.

В этом примере потребитель извлекает новый f44f3f11 уведомление, с согласованием содержимого, чтобы предпочесть Черепаха Формат RDF:

ПОЛУЧАТЬ https://example.org/inbox/f44f3f11 HTTP/1.1Принимать: application / ld + json; q = 0,9, текст / черепаха; q = 1,5

HTTP/1.1 200 OkТип содержимого: текст / черепаха @префикссхема:<http://schema.org/>.[асхема:Обзор Действия;схема:агент[асхема:Человек;схема:имя"Алиса"];схема:объект<https://example.org/article/5>;схема:результат[асхема:Рассмотрение;схема:reviewBody"Эта статья - лучшая, что я когда-либо видел!"]].

Реализации

Несколько Реализации LDN существуют,^[2][3] охват отправителей, потребителей и получателей, в том числе:

• докиели (отправитель, потребитель)
• эррол (отправитель)
• Fedora Commons (приемник)
• Апач Мармотта (приемник)
• Углеродный LDP (приемник)
• Связанные правила редактирования (отправитель)
• Твердый (отправитель, получатель, потребитель)
• Виртуозный универсальный сервер (получатель, потребитель)

Любой Платформа связанных данных (LDP) также соответствуют уведомлению о связанных данных. приемники поскольку LDN является строгим подмножеством LDP.^[2]

Рекомендации