Przypisywanie identyfikatorów URI do zasobów RDF

Question

Piszę aplikację na komputer przy użyciu technologii Gnome, a doszedłem do etapu Zacząłem planować obsługę Semantic Desktop.

Po wielu burzy mózgów, szkicowania pomysłów i modeli, pisanie i czytanie notatek dużo o RDF i tematów pokrewnych, w końcu wymyślił projekt planu.

Pierwszą rzeczą, którą postanowiłem zrobić, to zdefiniować sposób, w jaki podaję identyfikatory URI do zasobów i tutaj chciałbym poznać Twoją radę.

Mój program składa się z dwóch części:

1) na niższym poziomie, schematu RDF jest zdefiniowana. Jest to standardowy zestaw klas i właściwości , możliwych do rozszerzenia przez użytkowników, którzy chcą uzyskać więcej opcji (przy użyciu języka definicji przetłumaczonego na RDF).

2) Na wysokim poziomie użytkownik definiuje zasoby przy użyciu tych klas i właściwości .

Nie ma problemu z niższym poziomem, ponieważ model danych jest publiczny: nawet jeśli użytkownik zdecyduje się dodać nową zawartość, jest bardzo wdzięczna za udostępnienie jej innym użytkownikom i sprawienie, aby aplikacje innych osób miały więcej funkcji. Problem dotyczy z drugą częścią. Na wyższym poziomie użytkownik definiuje zadania, spotkania, terminy, plany i harmonogramy. Mogą one być prywatne, a użytkownik może preferować posiadanie jakichkolwiek informacji w URI, ujawniając źródło informacji .

Więc tutaj są pytania, mam na uwadze:

1) Który schemat URI należy używać? Nie mam strony internetowej ani stron internetowych , więc korzystanie z http nie ma sensu. Nie wydaje się również, aby sensownie używać innego standardowego identyfikatora URI zarejestrowanego w IANIE. Byłem rozważa dwie opcje: Użyj jakiś zwyczaj, mój własny, Uri nazwę systemu dla środków publicznych i użyć gołego URN dla podmiotów prywatnych, coś jak to:

urn : random_name_i_made_up : some_private_resource_uuid 

Ale zastanawiałem się, czy niestandardowy schemat URI to dobra decyzja, jestem otwarty, aby usłyszeć pomysły od Ciebie :)

2) Jak ukryć prywatne zasoby? Z jednej strony może być bardzo przydatne dla identyfikatora URI, aby określić, skąd pochodzi zadanie, zwłaszcza gdy zadania są udostępniane i delegowane między ludźmi. Z drugiej strony nie uwzględnia prywatności. Zastanowiłem się, czy mogę/powinienem/powinnam używać dwóch różnych stylów URI w zależności od ustawień użytkownika? Spowodowałoby to niespójność w postaci . Nie jestem pewien, co tutaj zrobić, ponieważ nie mam żadnego doświadczenia z URI w postaci . Mam nadzieję, że masz dla mnie jakąś radę.

Answer 1

1) Którego schematu URI należy użyć?

Polecam standard urn:uuid:, po którym następuje identyfikator UUID. Korzystanie z norm jest zwykle preferowane w stosunku do rozwiązań domowych!

2) Jak ukryć zasoby prywatne?

Nie używaj różnych schematów identyfikatorów. Próbowanie pieczenia autoryzacji i kontroli dostępu w schemacie tożsamości polega na mieszaniu warstw w sposób, który z pewnością spowoduje ból w przyszłości. Na przykład, co się stanie, gdy użytkownik udostępni publicznie niektóre prywatne treści (na przykład wersję roboczą) (jest to teraz w formie do opublikowania)?

Masz jedno, jednolite rozwiązanie identyfikatora, a następnie dostarcz jedną lub więcej usług, które mogą lub nie mogą rozwiązać dany identyfikator w dokumencie, w zależności od kontekstu (tożsamość użytkownika, metadane dotyczące samej treści itp.). Tak, to jest tak, jak zrobiłby to serwer HTTP, więc możesz zastanowić się, czy masz wbudowaną usługę HTTP w swojej architekturze. Jeśli nie, usługa, której potrzebujesz, będzie miała wiele podobieństw do HTTP, musisz tylko wyjaśnić okoliczności, w których identyfikator może zostać rozwiązany w dokumencie, co stanie się, gdy nie będzie to możliwe lub niedozwolone, itp.

Możesz również rozważyć, gdzie zamierzasz dodać największą wartość. Ponowne wymyślenie podstawowych protokołów dostępu do usługi może być zabawnym ćwiczeniem, ale użytkownicy mogą uzyskać większą wartość, jeśli ponownie wykorzystają standardowe komponenty na podstawowym poziomie usługi, a zamiast tego skoncentrują się na innowacjach i dodawaniu funkcji, gdy użytkownik faktycznie będzie miał dostęp do obiekty treści.