Уведомления о связанных данных
| Аббревиатура | ЛДН |
|---|---|
| Статус | Рекомендация W3C |
| Год начался | 2016 [1] [2] |
| Впервые опубликовано | 26 июля 2016 г [1] [2] |
| Последняя версия | Рекомендация W3C 2 мая 2017 г [3] |
| Предварительная версия | Черновик редактора 30 апреля 2017 г |
| Организация | |
| комитет | Рабочая группа по социальным сетям |
| Редакторы | |
| Базовые стандарты | |
| Сопутствующие стандарты | |
| Домен | Семантическая сеть , протокол связи |
| Веб-сайт | www |
Уведомления о связанных данных ( LDN ) [3] — это W3C рекомендация , которая описывает протокол связи , основанный на HTTP , URI и RDF, о том, как серверы ( получатели ) могут получать сообщения, передаваемые им приложениями ( отправителями ), а также как другие приложения ( потребители ) могут получать эти сообщения. Любой веб-ресурс (например, HTML- страница) может рекламировать конечную точку приема ( входящие ) для уведомлений. Сообщения выражаются в формате RDF и могут содержать произвольные данные.
Мотивация
[ редактировать ]Интернет . — это децентрализованная система веб-ресурсов, публикуемая множеством организаций и частных лиц Веб-ресурсы, такие как веб-страницы и более формально структурированные связанные данные , часто включают ссылки на другие ресурсы в сети и могут комментировать или описывать их различными способами. Однако принимающая сторона обычно не уведомляется о создании таких ссылок и, следовательно, не может предоставлять обратные ссылки без ручного вмешательства. Взаимодействия внутри платформ социальных сетей , такие как комментарии к новостной статье, в настоящее время «заблокированы» внутри платформы и недоступны через Интернет.
Существует несколько механизмов обратных ссылок , которые обычно используются между системами блогов , например, сообщение «ответа» в блоге B на сообщение в блоге A заставляет платформу B отправлять pingback для отображения в исходном блоге A. Однако эти механизмы Как правило, ограничены возможности отправки структурированной информации, а сами уведомления не являются частью децентрализованной сети и могут быть затруднены для использования каким-либо сторонним приложением.
Ключевой мотивацией LDN является поддержка уведомлений между децентрализованными веб-приложениями. [4] включая веб-браузеры, которые, не имея собственного 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.
- Получатель создает новый HTTP-ресурс , содержащий опубликованное уведомление, и отвечает
- Потребитель , извлекает RDF из обнаруженного URI входящего почтового ящика используя
GET, затем:- Потребитель анализирует тело ответа, чтобы найти операторы RDF со свойством
http://www.w3.org/ns/ldp#contains. Целью этих операторов является предоставление URI принятых уведомлений LDN. - Потребитель используя получает любое связанное уведомление,
GETи обрабатывать их RDF в соответствии с требованиями приложения. - Уведомления остаются доступными, поэтому их можно ссылаться на другие веб-ресурсы и описывать на них.
- Потребитель анализирует тело ответа, чтобы найти операторы RDF со свойством
На каждом этапе отправитель и потребитель могут выполнять согласование контента для отправки или получения в любом взаимно согласованном формате сериализации RDF , но совместимый получатель LDN должен поддерживать как минимум JSON-LD .
Примеры
[ редактировать ]Отправитель обнаруживает папку « или потребитель Входящие» для данного URI, в этом примере используя метод HEAD метод:
HEAD https://example.org/article/5 HTTP/1.1
HTTP/1.1 200 OK
Link: <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": "This article is the best I've ever seen!"
}
}
HTTP/1.1 201 Created
Location: http://example.org/inbox/f44f3f11
Потребитель : перечисляет содержимое обнаруженного почтового ящика и находит 3 уведомления
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",
]
}
Обратите внимание, что URI исходного ресурса, почтового ящика и уведомлений не обязательно должны размещаться на одном HTTP-сервере (например, они могут находиться в CDN ). Потребитель переходит по ссылкам для любых уведомлений , которые он хочет получить.
В этом примере потребитель получает новый f44f3f11 уведомление с согласованием содержимого, чтобы предпочесть формат 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 schema: <http://schema.org/> .
[ a schema:ReviewAction;
schema:agent [
a schema:Person;
schema:name "Alice"
];
schema:object <https://example.org/article/5>;
schema:result [
a schema:Review;
schema:reviewBody "This article is the best I've ever seen!"
]
] .
Реализации
[ редактировать ]Существует несколько реализаций LDN , [4] [5] охват отправителей, потребителей и получателей, в том числе:
- dokieli (отправитель, потребитель)
- ошибка (отправитель)
- Fedora Commons (приемник)
- Апач Мармот (приемник)
- Карбоновый ЛДП (ресивер)
- Связанные правила редактирования (отправитель)
- Твердый (отправитель, получатель, потребитель)
- Virtuoso Universal Server (получатель, потребитель)
Любые реализации платформы связанных данных (LDP) также соответствуют получателям уведомлений о связанных данных , поскольку LDN является строгим подмножеством LDP. [4]
Ссылки
[ редактировать ]- ^ Jump up to: а б «История публикаций уведомлений о связанных данных — W3C» . W3C . нд . Проверено 21 апреля 2021 г.
- ^ Jump up to: а б Кападисли, Сарвен; Гай, Эми, ред. (26 июля 2016 г.). «Уведомления о связанных данных» . W3C . Рабочая группа по социальным сетям. https://www.w3.org/TR/ldn/ . Проверено 21 апреля 2021 г.
- ^ Jump up to: а б с д Кападисли, Сарвен; Гай, Эми, ред. (02.05.2017). «Уведомления о связанных данных» . W3C . Рабочая группа по социальным сетям. https://www.w3.org/TR/ldn/ . Проверено 21 апреля 2021 г.
- ^ Jump up to: а б с Кападисли, Сарвен; Гай, Эми; Ланге, Кристоф; Ауэр, Сёрен; Самбра, Андрей; Бернерс-Ли, Тим (28 мая 2017 г.). «Уведомления о связанных данных: ресурсоориентированный протокол связи». Семантическая сеть . Конспекты лекций по информатике. Том. 10249. стр. 537–553. дои : 10.1007/978-3-319-58068-5_33 . ISBN 978-3-319-58067-8 . http://csarven.ca/linked-data-notifications .
{{cite book}}:|journal=игнорируется ( помогите ) - ^ «Отчеты и резюме испытаний LDN» . linkedresearch.org . 18 сентября 2016 г. Проверено 26 мая 2017 г.