Powiadomienia o połączonych danych

Powiadomienia o połączonych danych
Skrót	LDN
Status	Zalecenie W3C
Rok rozpoczęty	2016 ; 7 lat temu
Opublikowane po raz pierwszy	26 lipca 2016 ; 6 lat temu
Ostatnia wersja	; Zalecenie W3C z 2 maja 2017 r .; 5 lat temu
Wersja podglądu	; Wersja robocza redakcji 30 kwietnia 2017 r . ; 5 lat temu
Organizacja	W3C; Uniwersytet w Bonn; Uniwersytet w Edynburgu;
Komisja	Grupa robocza sieci społecznościowych
Redaktorzy	Sarven Capadisli; Amy Guy;
Normy bazowe	HTTP; URI; RDF; JSON-LD;
Powiązane normy	Połączona platforma danych; RDFa; żółw;
Domena	Sieć semantyczna , protokół komunikacyjny
Strona internetowa	www .w3 .org /TR /ldn /

Linked Data Notifications ( LDN ) to zalecenie W3C , które opisuje protokół komunikacyjny oparty na HTTP , URI i RDF , w jaki sposób serwery ( odbiorcy ) mogą odbierać wiadomości przesyłane do nich przez aplikacje ( nadawców ), a także w jaki sposób inne aplikacje ( konsumenci ) może odzyskać te wiadomości. Każdy zasób internetowy (taki jak HTML ) może anonsować odbierający punkt końcowy ( inbox ) dla powiadomień. Komunikaty są wyrażone w formacie RDF i mogą zawierać dowolne dane.

Motywacja

Sieć to zdecentralizowany system zasobów sieciowych publikowanych przez wiele organizacji i osób . Zasoby internetowe, takie jak strony internetowe i połączone dane o bardziej formalnej strukturze , często zawierają łącza do innych zasobów w sieci i mogą je komentować lub opisywać na różne sposoby. Strona otrzymująca nie jest jednak generalnie powiadamiana o utworzeniu takiego łącza, a zatem nie jest w stanie zapewnić linków zwrotnych bez ręcznej interwencji. Interakcje w mediach społecznościowych platformy, takie jak komentarze do artykułów informacyjnych, są obecnie „zablokowane” na platformie i trudno dostępne w Internecie.

kilka mechanizmów powiązań zwrotnych , które są powszechnie stosowane między systemami blogów , np. post „odpowiedzi” w blogu B na temat postu w blogu A powoduje, że platforma B wysyła pingback, który ma być pokazany na oryginalnym blogu A. Mechanizmy te są jednak ogólnie ograniczone, w których można przesyłać ustrukturyzowane informacje, a same powiadomienia nie stanowią części zdecentralizowanej sieci i mogą być trudne do wykorzystania przez jakąkolwiek aplikację strony trzeciej.

Kluczową motywacją dla LDN jest obsługa powiadomień między zdecentralizowanymi aplikacjami internetowymi, w tym przeglądarkami internetowymi, które - nie mając własnego serwera HTTP - nie są w stanie wygenerować łącza HTTP dla swoich wiadomości zwrotnych. Inną motywacją jest ustrukturyzowanie powiadomień jako instrukcji RDF przy użyciu dowolnego kontrolowanego słownictwa - tak, aby każda konsumująca aplikacja mogła wybrać konkretną informację, którą rozumie.

Protokół

Nadawca lub odbiorca wykonuje GET lub HEAD do istniejącego zasobu HTTP . Identyfikator URI skrzynki odbiorczej jest wykrywany na podstawie:
- Link : relacja w nagłówkach odpowiedzi HTTP typu http://www.w3.org/ns/ldp#inbox
- Instrukcja RDF osadzona w treści HTTP przy użyciu właściwości RDF http://www.w3.org/ns/ldp#inbox
Nadawca tworzy nowe powiadomienie (np. jako JSON -LD ), które POST wysyła do skrzynki odbiorczej URI.
- Odbiorca tworzy nowy zasób HTTP zawierający wysłane powiadomienie i odpowiada 201 Created oraz utworzonym identyfikatorem URI.
Konsument pobiera RDF z wykrytego identyfikatora URI skrzynki odbiorczej za pomocą GET , a następnie:
- Konsument analizuje treść odpowiedzi , aby znaleźć instrukcje RDF z właściwością http://www.w3.org/ns/ldp#contains . Przedmiotem tych instrukcji są identyfikatory URI akceptowanych powiadomień LDN.
- Konsument pobiera dowolne z połączonych powiadomień za pomocą GET i przetwarza swój RDF w sposób specyficzny dla aplikacji.
- Powiadomienia pozostają dostępne, dlatego można je łączyć i opisywać w innych zasobach internetowych.

Na każdym etapie nadawca i konsument mogą przeprowadzić negocjacje treści w celu wysłania lub odebrania w dowolnym wspólnie uzgodnionym formacie serializacji RDF , ale zgodny odbiornik LDN musi obsługiwać co najmniej JSON-LD .

Przykłady

Nadawca lub konsument odkrywa skrzynkę odbiorczą dla danego URI, w tym przykładzie za pomocą metody 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#skrzynka odbiorcza"

Nadawca wysyła powiadomienie do wykrytej skrzynki odbiorczej, w tym przykładzie używając słownika Schema.org :

  
 

  
   
    
     
  
    
      POST  https://example.org/inbox/7  HTTP  /  1.1  Content-Type  :  application/ld+json  {  "@context"  :  "http://schema.org"  ,  "@type"  :  "ReviewAction"  ,  " obiekt”  :  {  „@id”  :  „https://example.org/article/5”  },  „agent”  :  {  „@typ”  :  „Osoba”  , 
      
  
   
     
     
  
 "name"  :  "Alice"  },  "result"  :  {  "@type"  :  "Review"  ,  "reviewBody"  :  "Ten artykuł jest najlepszy, jaki kiedykolwiek widziałem!"  }  }

  
  HTTP  /  1.1  201  Utworzono  lokalizację  :  http://example.org/inbox/f44f3f11

Konsument wyświetla zawartość wykrytej skrzynki odbiorczej, aby znaleźć 3 powiadomienia :

  
  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/ skrzynka odbiorcza/7"  ,  "zawiera"  :  [  "https://example.org/skrzynka odbiorcza/5c6ca040"  ,  "https://cdn.example.org/skrzynka odbiorcza/92d72f00"  ,  "https://example.org/skrzynka odbiorcza /f44f3f11"  ,  ]  }

Pamiętaj, że identyfikatory URI oryginalnego zasobu, skrzynki odbiorczej i powiadomień nie muszą znajdować się na tym samym serwerze HTTP (np. mogą znajdować się w sieci CDN ) . Konsument podąża za linkami do wszelkich powiadomień, które chce pobrać .

W tym przykładzie konsument pobiera nowe powiadomienie f44f3f11 z negocjacjami treści preferującymi format Turtle RDF:

  
  GET  https://example.org/inbox/f44f3f11  HTTP  /  1.1  Zaakceptuj  :  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/>  .  [  schemat  :  ReviewAction  ;  _  schemat  :  agent  [  schemat  :  Osoba  ;  _  schemat  :  imię  "Alicja"  ];  schemat  :  obiekt  <https://example.org/article/5>  ;  schemat  :  
        
        
     
   wynik  [  schemat  :  Przegląd  ;  _  schema  :  reviewBody  "Ten artykuł jest najlepszy, jaki kiedykolwiek widziałem!"  ]  ]  .

Implementacje

kilka implementacji LDN , obejmujących nadawców, konsumentów i odbiorców, w tym:

dokieli (nadawca, konsument)
błąd (nadawca)
Fedora Commons (odbiornik)
Apache Marmotta (odbiornik)
Carbon LDP (odbiornik)
Powiązane reguły edycji (nadawca)
Stałe (nadawca, odbiorca, konsument)
Virtuoso Universal Server (odbiornik, konsument)

Wszelkie implementacje Linked Data Platform (LDP) są również zgodne z odbiornikami Linked Data Notification , ponieważ LDN jest ścisłym podzbiorem LDP.