Jednym z podstawowych celów projektu LarKC jest zgromadzenie powiązanej wiedzy dostępnej w chmurze otwartych danych (ang. Linked Open Data) i dostarczanie usług wydajnego wnioskowania na tych danych.

Czym zajmuje się projekt LarKC najlepiej obrazuje następujący Woordle:

Być może nie wspominałbym o tym projekcie gdyby nie opublikowane ostatnio zbiory danych:

• Baza zainteresowań naukowych pracowników naukowych związanych z informatyką; zawiera semantyczną reprezentację profili ponad 600 tysięcy naukowców; bazuje ona na otwartych danych udostępnionych przez serwis DBLP.
• Semantyczne repozytorium połączonych danych (ang. Linked Data Semantic Repository) zawiera ok 1.7 miliarda trójek zawierające powiązane dane pochodzące z różnych serwisów zarządzających wiedzą ogólną, w tym DBPedia, Freebase, Geonames, MusicBrainz, UMBEL, czy znany nam już Wordnet. Na tych danych zostało dodatkowo przeprowadzone wnioskowanie zgodnie z regułami zawartymi w powiązanych ontologiach.
• Połączone dane nauk przyrodniczych (ang. Linked Life Data) prawdopodobnie najciekawsza baza, zawierająca ok 5 miliarda trójek z informacjami biomedycznymi powiązanymi pomiędzy poszczególnymi zestawami danych, które zostały zintegrowane w tej bazie.

Jeżeli zastanawiacie się dlaczego poświęciłem dzisiejszy artykuł projektowi LarKC, to odpowiedź jest bardzo prosta: w poniedziałek opowiem o języku zapytań SPARQL, a nowo nabytą wiedzę będziecie mogli przetestować na dwóch ostatnich z zaprezentowanych repozytoriów: LDSR i Linked Life Data.

A teraz, załóżmy, że supermarket to nasz serwis internetowy, a my jesteśmy agentem semantycznym próbującym uzyskać dostęp do poprzednio zidentyfikowanego źródła informacji. W momencie kiedy nasze położenie dokumentów i usług zmienia się na naszym serwisie, nie agent semantyczny (i nie tylko) musi na nowo sporządzić sobie mapę serwisu (czyli zaindeksować go).

Jak możemy ustrzec siebie i nasz serwis przez niestabilnymi URLami, które będą się zmieniały ? Rozwiązaniem promowanym m.in. przez sir Tima Bernersa-Lee są tak zwane "Cool URIs" (czyli "odjazdowe" URI), które nie ulegają zmianie.

Według TBL, kluczową kwestią w projektowaniu schematów URI jest zapewnienie ich niezmienności w czasie. Dzięki temu dany zasób lub usługa będzie zawsze dostępna pod tym samym adresem. Tak na marginesie, to podobne podejście ma środowisko bibliotekarzy; nie ma się co dziwić, w końcu od wieków muszą odnajdywać książki w przepastnych bibliotekach.

Wielu z was zapewne stwierdzi, że niezmienne URI to ciekawa naukowa wizja, ale w rzeczywistości; wymienicie nawet kilka kontr-przykładów:

1. Konieczność przeorganizowanie serwisu - po pewnym czasie doszliście do wniosku, że obecny sposób funkcjonowania waszego systemu i tego jakie URLe są generowane musi zostać poprawiony; tym samym schemat URI waszego serwisu ulegnie zmianie. To prawda, tak się może zdarzyć i niestety zdarza się zbyt często. A powód jest zazwyczaj jeden i ten sam: w czasie projektowania serwisu nie przemyślano dobrze architektury informacji i usług, a jedynie skupiono się (jeśli wogóle) na architekturze samego systemu. To doprowadziło do problemów z reprezentacją identyfikatorów zasobów.Wniosek: projektowanie architektury informacji jest równie ważne (o ile nie ważniejsze) od projektu samego systemu; system zawsze można poprawić, zmienić technologię, ale URI są jego interfejsem dla innych usług, i nie należy tego zaniedbywać.
   
2. Prawa dostępu - może się zdarzyć, że w natłoku dokumentów, którymi zarządza nasz system będziemy zmuszeni do zmiany uprawnień dostępu do nich. Jeżeli nasze URI będą budowane w oparciu o tę informację, np:
   • /archive/documents/123 - dla dokumentów archiwalnych,
   • /secret/documents/234 - dla dokumentów prywatnych,
   • /public/documents/345 - dla dokumentów publicznych,
3. to przenoszenie dokumentów np. do archiwum, powoduje że ich identyfikator się zmienia, i wszystkie referencje w innych dokumentach powinny zostać zaktualizowane.Rozwiązanie: przechowywać informacje o stanie i prawie dostępu na poziomie metadanych i stosować jednolity schemat URI dla wszystkich dokumentów w systemie.
4. Dokument zmienił swoje miejsce na dysku - sytuacja kiedy jeden z pracowników przejmuje obowiązki kolegi w czasie jego urlopu, i w tym czasie część dokumentów jest dostarczana z jego przestrzeni dyskowej zamiast z przestrzeni dyskowej kolegi, mogłaby teoretycznie prowadzić do zmiany adresu URL tych dokumentów, np. z /~pracownikA/documents/123.pdf do /~pracownikB/documents/123.pdf. .Rozwiązanie: wykorzystać mechanizmy mapowania dostarczne przez serwery HTTPD (np. Apache).
5. Zmiana implementacji usługi wystawiającej dokumenty - pierwsza wersja systemu powstała w PHP, a teraz z uwagi na wydajność musimy zaimplementować nasze usługi w JEE; w najlepszym wypadku będziemy musieli zmienić rozszerzenia skryptów z php na jsp. Ale przecież nie musiało do tego dość, tworzone przez nas schematy URI powinny być niezależne od implementacji danej usługi. Podpowiedź: ponownie mogą nam pomóc mechanizmy mapowania i przekierować dostarczane przez serwery HTTPD; część środowisk  umożliwia definiowanie schematów bez "rozszerzeń", np. JEE za pomocą serwletów.
6. URN vs URI - z założenia unikalne i niezmienialne miałybyć URN (ang. Universal Resource Name). To prawda, ale sam schemat HTTP z którego chcemy korzystać w URI, nie uniemożliwia niezmienialności identyfikatorów. Niestety, zazwyczaj jesteśmy sami winni temu, że one się zmieniają.
7. Brak odpowiednich narzędzi - chyba najczęstrza wymówka. Niestety dla wielu prawdziwa. Jedyne co mogę tutaj zaoferować to pomoc z naszej strony w dobraniu lub wyprodukowaniu odpowiednich rozwiązań.

Podsumowując, czego nie umieszczamy w URI?

1. Nazw i nazwisk - np. dokumentów, twórców, włascicieli
2. Tematow, klasyfikacji, opisów
3. Stanu dokumentów
4. Praw dostepu
5. Typów plików i ich rozszrzeń
6. Informacji o implementacji danej usługi dostarczającej dokumenty, np. PHP lub JSP.

Pamiętajmy również, że nazwa domeny jest częścia URI - więc trzeba zapewnić, żeby się nie zmieniała.