Link

Pobierz książkę w formacie epub Pobierz książkę w formacie pdf

Warto przestać traktować link tylko jako adres jakiegoś zasobu w Sieci. URL to naprawdę potężne narzędzie, właściwie osobny interfejs do korzystania z treści publikowanych w Internecie. Tak właśnie twierdzi Jakob Nielsen, jeden z czołowych ekspertów użyteczności projektów internetowych, od lat 90. rozwijający swoją (co prawda nieco konserwatywną) teorię projektowania i budowania przyjaznych użytkownikom interfejsów. Linki to także ważne interfejsy do nowocześnie udostępnianych zbiorów cyfrowych dziedzictwa. ¶1

Czym w ogóle jest URL (ang. Uniform Resource Locator)? To po prostu pewien standard adresowania zasobów w Internecie lub sieciach lokalnych, zawierający w sobie informacje o protokole niezbędnym do dotarcia do zasobu (na przykład http, https czy ftp) oraz adresie serwera i ścieżce dostępu. URL jest podstawą linkowania – jeśli na własnej stronie dodajemy zachętę do przejścia na jakąś inną, linkując, musimy podać sposób, w jaki można do niej trafić. To rozwiązanie przestaje być prostą oczywistością (której nie warto byłoby przytaczać), kiedy bliżej poznamy niektóre mechanizmy rządzące dzisiejszym Webem. ¶2

Oto jeden z nich. Czytałem już przynajmniej kilka prac naukowych, w których przypisy odwołujące się do Internetu pisane były w dość radykalny sposób. Zamiast konkretnego adresu URL wskazującego na docelową domenę i ścieżkę dostępu, autor lub autorka podawali link, wygenerowany po wpisaniu adresu lub jakiejś frazy w wyszukiwarce Google. Pośrednictwo Google w nawigowaniu w sieci WWW jest dominujące i dla wielu osób ta wyszukiwarka jest właściwie podstawowym narzędziem trafiania do konkretnych stron internetowych. Zamiast wpisywać adres w pasku przeglądarki, wpisują go do formularza Google i klikają w pierwszy link z wygenerowanej listy. Google nie jest tu zresztą jedynym pośrednikiem. Linki publikowane na Twitterze są automatycznie skracane, aby zaoszczędzić miejsce na tekst w 140-znakowej wiadomości. Użytkownicy mogą też skracać je samodzielnie, korzystając z wielu darmowych serwisów. Mechanizm ten uzależnia jednak linkowanie od dostępności serwisu pośredniczącego i bywa częstym źródłem nieaktualności adresów URL (czyli problemu określanego jako link rot). ¶3

Innym wielkim wyzwaniem są efekty linkowania. Na pierwszy rzut oka wydaje się, że dwie osoby korzystające w dwóch przeglądarkach z tych samych adresów URL otrzymają dokładnie te same strony internetowe. Wcale tak nie musi być. Po pierwsze, protokół http, umożliwiający wyświetlanie stron w przeglądarce, zawiera w sobie funkcję, która pozwala przeglądarce na negocjowanie ostatecznej postaci generowanej strony WWW (Content Negotiation). Przykładowo, kiedy jedna z osób posiada przeglądarkę w systemie posługującym się językiem angielskim, a druga korzysta z systemu w języku polskim, przeglądarki mogą poprosić docelowy serwer o wygenerowanie strony w języku zgodnym z językiem systemu. Obie osoby dostaną wtedy – po wpisaniu tego samego adresu URL – strony w różnych wersjach językowych. Różnicowanie efektów posługiwania się identycznymi URL-ami umożliwia także pogłębiająca się nieustannie personalizacja Webu. ¶4

Coraz więcej serwisów internetowych zbiera informacje o własnych użytkownikach, wykorzystując je do publikowania bardziej dostosowanych treści. Prostym, ale bardzo czytelnym przykładem jest Facebook. Różne osoby, poproszone o wejście na stronę Facebook.com, otrzymają różne treści, dostępne wciąż pod tym samym adresem URL. Naprawdę, nie ma sensu wierzyć w jakąś niezwykłą neutralność adresowania we współczesnym Internecie. Jeśli dodamy do tego fakt, że strony przeglądamy dziś nie tylko na komputerach, ale też na komórkach, zegarkach, telewizorach czy lodówkach, może okazać się, że pod tym samym adresem URL użytkownik mobilny znajdzie treść odrobinę lub mocno różną od tego, co zobaczyłby na ekranie laptopa.
Mechanizmy te podważają klasyczny sposób tworzenia przypisów odwołujących się do Internetu w pracach naukowych, ale z punktu widzenia instytucji dziedzictwa publikującej w Sieci swoje zbiory to także poważne wyzwania, niebezpieczna niestałość w potencjalnie wysoko ustandaryzowanych mechanizmach przetwarzania i wyświetlania informacji. Link, z elementu porządkującego i stałego, staje się kolejną dynamiczną i niepewną częścią codziennego doświadczania Webu. ¶5

Przyjazne adresowanie

Można jednak korzystanie z Sieci uczynić bardziej przyjaznym. Dobrą praktyką uczłowieczania adresowania w Internecie jest stosowanie tak zwanych linków semantycznych, czyli takiej postaci URL-i, która jest w stanie powiedzieć coś nie tylko przeglądarce i serwerowi, ale też człowiekowi. Można to zilustrować przykładem z serwisu Śląskiej Biblioteki Cyfrowej. W domenie sbc.org.pl znajduje się podstrona listująca zawartość kolekcji „Archiwalia”. Gdyby stosowano tam linkowanie semantyczne, adres listy zbiorów w tej kolekcji wyglądać mógłby tak: ¶6

  • http://www.sbc.org.pl/kolekcja/archiwalia

a użytkownik przeglądający tę listę mógłby przechodzić przez kolejne jej strony za pomocą adresów w postaci: ¶7

http://www.sbc.org.pl/kolekcja/archiwalia/2
http://www.sbc.org.pl/kolekcja/archiwalia/3
http://www.sbc.org.pl/kolekcja/archiwalia/4 ¶8

Niestety, lista archiwaliów dostępna jest tam pod adresem w postaci, której nikt nie jest w stanie zapamiętać: ¶9

  • http://www.sbc.org.pl/dlibra/collectiondescription?dirids=150

Konsorcjum W3C, rozwijające standardy dla sieci WWW, w jednym ze swoich dokumentów wskazało na trzy cechy dobrych adresów URL. Powinny one być: ¶10

  • proste,
  • stabilne i
  • umożliwiające zarządzanie nimi.

Punkt pierwszy jest oczywisty wobec tego, co napisałem wyżej o URL-ach semantycznych. Punkt drugi wskazuje na przykład na konieczność unikania tworzenia adresów wskazujących na konkretną technikę budowania stron: adres w postaci http://domena.pl/dokument.php przestanie być aktualny, kiedy serwis, do którego kieruje, zacznie być napędzany nie kodem w języku PHP, ale na przykład w technice ASP, i końcówki adresów automatycznie zmienią się na dokument.asp. Można to oczywiście obejść, ale po co generować niepotrzebne problemy. Punkt trzeci tych krótkich wytycznych – „zarządzalność” adresów URL – to tak naprawdę dbanie o to, aby praca z nimi i ewentualne zmiany były jak najłatwiejsze do wdrożenia i nie powodowały sytuacji, w której zmiana systemu zarządzania stroną sprawia, że duża część dotychczasowych linków traci ważność. Warto wziąć to pod uwagę już na etapie projektowania serwisu. ¶11

Prostota i czytelność linków to nie jedyna rzecz, o którą warto zadbać, projektując adresowanie w serwisie udostępniającym zbiory cyfrowe. Podczas jednych z warsztatów w LaCH UW pracowaliśmy z zasobami portalu Internetowego Polskiego Słownika Biograficznego. To nowoczesny, dynamiczny serwis, który publikuje biogramy opracowywane dla wydawanego od 1935 roku Polskiego Słownika Biograficznego. Wyszukiwanie zaawansowane, przeszukiwanie treści biogramów czy wizualizacja powiązań między osobami to tylko niektóre z udogodnień, jakie umożliwia wersja cyfrowa Słownika. Naszym celem było jednak skorzystanie z niego w nieco niestandardowy sposób. Chcieliśmy automatycznie pobrać i przetworzyć do postaci tabeli w arkuszu kalkulacyjnym wybrane informacje o polskich poetach i poetkach. ¶12

Pod adresem ¶13

uzyskaliśmy listę wszystkich poetów, których biogramy dostępne są w serwisie Słownika. Aby pobrać wybrane informacje z ich treści, musieliśmy pozyskać linki do stron poszczególnych osób. Strona wyświetlająca listę biogramów pozwalała nam na ustawienie wyświetlania 10, 20 lub 50 linków na jednej stronie. Niestety, bez względu na nasz wybór adres aktualnej strony pozostawał ten sam. Chcąc automatycznie pobrać linki z poszczególnych podstron listy poetów, także potrzebowaliśmy ich dokładnych adresów. Okazało się jednak, że nie jest to możliwe – adres pierwszej strony listingu był identyczny z adresem strony dziesiątej. Jak w takim razie mielibyśmy – wykorzystując dowolny program, pozwalający na pobieranie treści z Webu – zapisać na dysku poszczególne podstrony? ¶14

Polecenie w stylu: ¶15

  • pobierz pierwszą podstronę listy
  • pobierz drugą podstronę listy
  • pobierz trzecią podstronę listy

nie da pozytywnego rezultatu, bo program – niedziałający przez przeglądarkę – ściągnie za każdym razem tę samą, pierwszą podstronę listy. ¶16

A przecież nie tak powinno to funkcjonować. Wspomniany na samym początku Jakob Nielsen zaproponował dwie bardzo proste do zrozumienia zasady, dotyczące projektowania adresów stron serwisu internetowego, znajdujących się w hierarchii niżej niż strona główna, dostępna zawsze po wpisaniu pełnej nazwy domeny. Po pierwsze, adresy URL, wskazujące na poszczególne podstrony serwisu, powinny w prosty i czytelny sposób oddawać jego strukturę. Po drugie, powinny być hakowalne – to znaczy użytkownik, chcąc dotrzeć do treści znajdujących się głębiej w strukturze serwisu, powinien być w stanie łatwo zbudować własną postać adresu URL, która go do nich doprowadzi. Chodzi o to, aby poruszanie się po serwisie za pomocą modyfikacji adresu wpisywanego do przeglądarki było możliwie intuicyjne. ¶17

Hakowanie adresów

Do tej pory wspominałem głównie o problemach z URL-ami. Jak widać, nie są to niezależne i neutralne wskaźniki. Jednak ich dynamiczny charakter ma też swoje dobre strony. Personalizacja, którą wspomniałem wyżej przy okazji adresu URL Facebooka, może mieć też pozytywny efekt i pozwolić instytucji lepiej dostosować swoją stronę główną do profilu korzystającego z niej użytkownika. Coraz skuteczniejsze systemy śledzenia użytkowników online i dostępne dane pozwalają głęboko sprofilować treść docelowej strony, kształtując ją tak, aby wyświetlała tylko te treści, które mają największą szansę zainteresować użytkownika. Wersję strony głównej muzeum różnicować można pod względem języka (prosty dla użytkowników z niskiego przedziału wiekowego, bardziej profesjonalny dla użytkowników identyfikowanych jako osoby interesujące się sztuką itp). Na ile jest to etyczne w kontekście prawa użytkowników do prywatności, to już inna sprawa. ¶18

Ale pójdźmy dalej. Skoro URL to nie tylko proste adresowanie, ale też kształtowanie pokazywanej w przeglądarce treści, można zacząć traktować go jako interfejs do bazy danych. A to już prosta droga do tego, żeby planować zupełnie nowe sposoby korzystania ze zbiorów, które udostępniamy online. ¶19

Kiedy mamy do czynienia z adresami w postaci ¶20

  • http://adresbiblioteki.org/archiwalia
  • http://adresbiblioteki.org/czasopisma

wiemy, że manipulując ostatnim elementem adresu (tym po nazwie domeny i znaku /), możemy prosić bazę danych serwisu o treści konkretnego rodzaju (literatury albo muzyki). To proste i oczywiste rozwiązanie. Można byłoby jednak pójść dalej i zamiast korzystać z dostępnej na stronie wyszukiwarki, wprowadzić do przeglądarki adres w takiej postaci: ¶21

  • http://adresbiblioteki.org/czasopisma/temat/sztuka

Taki adres mógłby wygenerować stronę zawierającą listę odnośników do stron tytułów czasopism o sztuce. Gdybyśmy dodali jeszcze taki element do adresu: ¶22

  • http://adresbiblioteki.org/czasopisma/temat/sztuka/xml

moglibyśmy otrzymać – jako rezultat zapytania – plik tekstowy o określonej strukturze (xml czy JSON), który zawierałby podstawowe informacje o czasopismach i odpowiednie odnośniki. Taka postać informacji zwrotnej pozwala ją w prosty sposób przetworzyć, na przykład do pliku Excela – jeśli robilibyśmy jakąś większą kwerendę w tej bibliotece, taka możliwość manipulowania adresami byłaby bardzo pomocna. To, z czym pracowaliśmy, to proste API – interfejs programistyczny, pozwalający także w automatyczny sposób pobierać konkretne informacje ze stron internetowych. ¶23

Wiele muzeów, bibliotek i archiwów cyfrowych udostępnia API do swoich zbiorów. Czasem jest to API publiczne, z którego korzystać można bez autoryzacji, czasem jednak wymagane jest – w zapytaniu lub bezpośrednio przed nim – podanie odpowiednich danych autoryzujących nas w systemie. To trochę jak posiadanie klucza do mieszkania – żeby wejść, musimy nie tylko znać adres i sposób dotarcia do niego, ale też mieć czym otworzyć drzwi. ¶24

API Źródło dokumentacji
National Archives http://www.nationalarchives.gov.uk/help/discovery-for-developers-about-the-application-programming-interface-api/
Harvard Art Museums http://www.harvardartmuseums.org/collections/api
Walters Art Museum Collections http://api.thewalters.org
Deutschen Digitalen Bibliothek https://api.deutsche-digitale-bibliothek.de/doku/display/ADD/API+der+Deutschen+Digitalen+Bibliothek
Koninklijke Bibliotheek (Biblioteka Narodowa Holandii) https://www.kb.nl/en/resources-research-guides/data-services-apis
Polona https://polona.pl/api/

API pozwala na skuteczne kwerendy i jednorazowe pobieranie dużej ilości informacji o zbiorach cyfrowych, ale również na tworzenie rozmaitych narzędzi i aplikacji bazujących na udostępnianych danych: ¶25

Art Up Your Tab rozszerzenie do przeglądarki Chrome, umieszczające w tle nowej karty losowy obraz ze zbiorów agregowanych przez Europeanę
Culturepics aplikacja proponująca losowe materiały wizualne z Europeany, dostępne pod modyfikowanymi URLami (np. http://culturepics.org/156×252), do wykorzystania w projektowaniu interfejsów
EEXCESS Google Docs Plugin wtyczka do aplikacji Google Docs, proponująca kontekstowo do pisanego tekstu treści z Europeany
Unbubble.eu wyszukiwarka wykorzystująca dane m.in. z Europeany i pozwalająca na wyszukiwanie bez profilowania i bańki filtrującej
DPLA/Europeana query aplikacja umożliwiająca symultaniczne przeszukiwanie zbiorów agergowanych przez Europeanę i Digital Public Library of America

Oczywiście, jeśli udostępnia się publicznie przez API informacje o zbiorach, robi się to metodą „tylko do odczytu”, nie zezwalając na jakąkolwiek zdalną i nieautoryzowaną modyfikację tych danych w bazie. Istnieje natomiast szczególny rodzaj API, który pozwala na zdalne przetwarzanie wizualnych zbiorów cyfrowych – dzieje się to jednak wyłącznie po stronie użytkownika i nie wpływa na oryginalną postać plików udostępnianych przez bibliotekę czy archiwum. Standard takiego API, określany skrótem IIIF (International Image Interoperability Framework), rozwijany jest od 2011 roku przez konsorcjum Biblioteki Brytyjskiej, uniwersytetów Stanforda i Cornella, bibliotek narodowych Francji i Norwegii oraz Los Alamos National Laboratory Research Library. IIIF ma ułatwić pracę ze zbiorami wizualnymi w bibliotekach, archiwach czy muzeach cyfrowych oraz umożliwiać interoperacyjność udostępnianych tam danych. ¶26

Muzeum cyfrowe, udostępniające wizerunki obiektów (skany 2D) także za pomocą standardu IIIF, umożliwia użytkownikom edytowanie ich bezpośrednio w przeglądarce za pomocą manipulowania adresem URL. Pozwala także na automatyczne pozyskiwanie informacji o skanie, łącznie z ewentualną warstwą transkrypcji, oznaczonymi elementami skanu czy metadanymi. ¶27

Linki a media społecznościowe

Rozdział o adresach URL byłby niepełny bez odniesienia do tego, co dzieje się z linkami w mediach społecznościowych. Są one ważnym źródłem ruchu na stronie udostępniającej zbiory, pozwalają też niektórym materiałom rozpowszechniać się bardzo szeroko metodą wirusową. Jednak kiedy na Facebooku lub Twitterze publikujemy jakiś link, staje się on czymś więcej niż zapisanym w bazie danych zwykłym adresem w standardzie URL. Facebook i Twitter traktują linki jako obiekty, którym nadają określone właściwości i które przetwarzają we własnych celach komercyjnych. Niektórzy sądzą nawet, że we współczesnym Webie linki jako autonomiczny fragment informacji jest w zdecydowanym odwrocie. Irański bloger i aktywista Hossein Derakhshan w wywiadzie dla „Dwutygodnika” (Polityka Hiperlinków, 2016) mówił: ¶28

Hiperlinki, które stanowiły fundament sieci, są dziś tłamszone i poskramiane przez media społecznościowe. Zyski z reklamy stały się tak ogromne, że wielkie portale społecznościowe robią wszystko, aby ich użytkownicy nigdy nie przekraczali ich granic. Instagram w ogóle nie daje możliwości używania linków. Facebook dopuszcza tylko jeden link w poście, traktuje go jednak jako obiekt, a nie relację. Hiperlinki na Facebooku zostają zamienione w obraz, który dopiero wtórnie – za pośrednictwem wewnętrznego systemu analitycznego – przenosi cię na zewnątrz. To zmiana jednocześnie bardzo subtelna i upiorna. ¶29

Jeśli dodać do tego wynikające z rozmaitych interpretacji prawa autorskiego pytania o legalność linkowania w ogóle, otrzymamy dość niewesoły obraz Webu jako zdominowanej przez wielkich graczy i restrykcyjne prawo przestrzeni. Niestety nie bardzo wiadomo, jak odpowiadać na taką interpretację webowej rzeczywistości. Trudno oczekiwać przecież, że instytucje kultury, do których misji należy też maksymalna dostępność informacyjna, odwrócą się od mediów społecznościowych albo usuną swoje linki z Google. Tego rodzaju cyfrowe samobójstwo może być opcją pewnie tylko dla tych nielicznych jednostek, których status i dochody umożliwiają całkowitą rezygnację z nieustającej walki o uwagę w Internecie. Jestem jednak przekonany, że da się dość prostymi sposobami nadwyrężać – na niewielką skalę – te webowe monopole. Instytucje kultury mogłyby się poczuć do tego zobligowane – w końcu w ich działalności w Sieci chodzi o coś więcej niż prosty zysk informacyjny i zasięg. ¶30

Mogą one, aktywnie działając w mediach społecznościowych, równocześnie dbać o to, aby publikowane tam treści były dostępne także poza nimi. Nie można wymagać od wszystkich, żeby posiadali konto na Twitterze czy Facebooku i od tego uzależniać prawa dostępu do określonych zasobów czy informacji. ¶31

Dbanie o dostępność treści z mediów społecznościowych nie musi być trudne. Przykładowo Facebook i Twitter pozwalają w łatwy sposób wygenerować i pobrać archiwum publikowanych tam przez użytkownika treści. Archiwum takie można po prostu umieścić na ogólnie dostępnej stronie WWW instytucji – robią tak na przykład ministerstwa rządu Wielkiej Brytanii z archiwami swoich kont twitterowych. Innym sposobem jest wykorzystanie newslettera – wpisy publikowane na Facebooku czy Twitterze można, za pomocą odpowiedniego skryptu, automatycznie republikować w bazie danych, na podstawie której co jakiś czas do subskrybentów rozsyłana może być zbiorcza wiadomość. ¶32

Oprócz dostępności treści z mediów społecznościowych, poza tymi mediami ważne jest jednak także to, jak linki serwisów instytucji kultury prezentują się w tych przestrzeniach. Cytowany wyżej Derakhshan podkreślał, że link w przestrzeni Facebooka czy Twittera to obiekt, przetwarzany dalej przez algorytmy tych serwisów. Rzeczywiście tak jest i można z tej sytuacji skorzystać, odzyskując przynajmniej część kontroli nad własnymi linkami. Każdą stronę serwisu uzupełnić można o specjalne zestawy metadanych (Open Graph dla Facebooka i Cards dla Twittera), pozwalające na zdefiniowanie tego, jak wyglądać będzie obrazek poglądowy udostępnianej tam strony, jaki tytuł i jakie streszczenie zostanie jej nadane. Jeśli nie zadbamy o poprawne zdefiniowanie tych informacji, zostaną one pobrane – lub wygenerowane – automatycznie. ¶33