Уведомления о связанных данных

Уведомления о связанных данных
Положение дел	Рекомендация W3C
Впервые опубликовано	2017-05-02
Организация	Консорциум World Wide Web
Редакторы	Сарвен Кападисли, Эми Гай
Базовые стандарты	HTTP , URI , RDF , JSON-LD
Связанные стандарты	Платформа связанных данных , RDFa , Turtle
Домен	Семантическая сеть , протокол связи
Сокращение	LDN
Интернет сайт	www .w3 .org / TR / ldn /

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

Мотивация [ править ]

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

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

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

Протокол [ править ]

А отправитель или приемник выполняет GETили HEADк существующему HTTP ресурса. Его URI почтового ящика определяется одним из следующих способов:
- Link:Отношение в заголовках ответа HTTP - типаhttp://www.w3.org/ns/ldp#inbox
- Заявление RDF, встроенное в тело HTTP с использованием свойства RDF http://www.w3.org/ns/ldp#inbox
Отправитель создает новое уведомление (например , в виде JSON-LD ), который он POSTS в почтовый ящик URI.
- Приемник создает новый HTTP - ресурс , содержащий публикуемые уведомления и отвечает 201 Createdи созданному URI.
Потребитель извлекает RDF из обнаруженных входящей URI с помощью GET, а затем:
- Потребитель разбирает тело ответа , чтобы найти заявление RDF с имуществом http://www.w3.org/ns/ldp#contains. Объект этих операторов предоставляет URI для принятых уведомлений LDN.
- Потребитель получить какой - либо из связанных с использованием уведомления GETи обрабатывать их RDF в приложении-специфическим образом.
- Уведомления остаются доступными и, следовательно, могут быть связаны с другими веб-ресурсами и описаны в них.

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

Примеры [ править ]

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

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

HTTP / 1.1  200  OK Ссылка :  <https://example.org/inbox/7>; rel = "http://www.w3.org/ns/ldp#inbox"

Отправитель посылает уведомление выявленного почтового ящика, в этом примере с помощью 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" :  "Лучшая статья из всех, что я когда-либо видел!" } }

HTTP / 1.1  201  Создано Расположение :  http://example.org/inbox/f44f3f11

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

ПОЛУЧИТЬ  https://example.org/inbox/7  HTTP / 1.1 Content-Type :  application / ld + json

HTTP / 1.1  200  ОК 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 " ,  ] }

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

В этом примере потребитель получает новое f44f3f11уведомление с согласованием содержимого, чтобы предпочесть формат Turtle RDF:

GET  https://example.org/inbox/f44f3f11  HTTP / 1.1 Принять :  application / ld + json; q = 0.9, text / turtle; q = 1.5

HTTP / 1.1  200  OK Content-Type :  текст / черепахаСхема @prefix : <http://schema.org/> .    [ В схему: ReviewAction ;   схема: агент [  схема: Person ;  схема: имя "Алиса"  ]; схема: объект <https://example.org/article/5> ;  схема: результат [  схемы: обзор ;  schema: reviewBody "Это лучшая статья, которую я когда-либо видел!"  ] ] .

Реализации [ править ]

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

dokieli (отправитель, потребитель)
errol (отправитель)
Fedora Commons (получатель)
Apache Marmotta (получатель)
Carbon LDP (ресивер)
Связанные правила редактирования (отправитель)
Твердый (отправитель, получатель, потребитель)
Virtuoso Universal Server (получатель, потребитель)

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

Ссылки [ править ]

^ Capadisli, Sarven; Гай, Эми, ред. (2017-05-02). «Уведомления о связанных данных» . Рекомендация W3C . https://www.w3.org/TR/ldn/ .
^ a b c Кападисли, Сарвен; Гай, Эми; Ланге, Кристоф; Ауэр, Сорен; Самбра, Андрей; Бернерс-Ли, Тим (2017-05-28). Уведомления о связанных данных: ресурсо-ориентированный протокол связи . Семантическая сеть. ESWC 2017. Конспект лекций по информатике . Конспект лекций по информатике. 10249 . С. 537–553. DOI : 10.1007 / 978-3-319-58068-5_33 . ISBN 978-3-319-58067-8. http://csarven.ca/linked-data-notifications .
^ «Отчеты об испытаниях LDN и сводка» . connectedresearch.org . Проверено 26 мая 2017 .

[1] Capadisli, Sarven; Гай, Эми, ред. (2017-05-02). «Уведомления о связанных данных» . Рекомендация W3C . https://www.w3.org/TR/ldn/ .

[sarven2017-2] Кападисли, Сарвен; Гай, Эми; Ланге, Кристоф; Ауэр, Сорен; Самбра, Андрей; Бернерс-Ли, Тим (2017-05-28). Уведомления о связанных данных: ресурсо-ориентированный протокол связи . Семантическая сеть. ESWC 2017. Конспект лекций по информатике . Конспект лекций по информатике. 10249 . С. 537–553. DOI : 10.1007 / 978-3-319-58068-5_33 . ISBN 978-3-319-58067-8. http://csarven.ca/linked-data-notifications .

[3] «Отчеты об испытаниях LDN и сводка» . connectedresearch.org . Проверено 26 мая 2017 .

[1]