Bazy danych w zastosowaniu telekomunikacyjnym

Transkrypt

Bazy danych w zastosowaniu telekomunikacyjnym
prof. Czesław Jędrzejek*, Tomasz Olejniczak, Maciej Kucewicz
Instytut Technik Telekomunikacyjnych i Informatycznych, Poznań
*także Zakład Systemów Telekomunikacyjnych
Akademii Techniczno – Rolniczej w Bydgoszczy
Podstawy zarządzania informacją w Internecie
STRESZCZENIE
Internet w większości zawiera nieuporządkowaną informację. Dostęp poprzez URL nie spełnia wymagań
korzystania z bibliotek cyfrowych. IETF zamierza wprowadzić „Handle System”, ogólny schemat dostępu do obiektów
cyfrowych w środowisku rozproszonym. System ten wprowadza uniwersalną przestrzeń adresową oraz znaczniki
„handle” dostępu do informacji o następujących cechach:
→ globalna unikatowość,
→ trwałość,
→ wielokrotność informacji,
→ rozszerzalna przestrzeń adresowa,
→ oparcie o UNICODE 2.0,
→ rozproszony model usług i zarządzania,
→ zapewnienie bezpieczeństwa i wartości intelektualnych treści,
→ efektywny tryb wyszukiwania.
„Handle System” ułatwi wprowadzenie wielu usług, np. globalnego cache’u, typu zaimplementowanego przez firmę
Akamai. Będzie on miał duże znaczenie dla trybu korzystania z baz danych.
WSTĘP
Podstawą działania Internetu jest transmisja pakietowa i system adresowy protokołu IP.
Ułatwienie w postaci DNS (Domain Name System) działa na zasadzie książki telefonicznej przekształca nazwę na adres cyfrowy. Gwałtowny wzrost Internetu prowadzi do zaśmiecenia
informatycznego. Oprócz informacji wartościowej (często płatnej) pojawia się ogromna ilość
informacji małowartościowej, amatorskiej i niezarządzanej.
Mimo upowszechnienia protokołu XML oraz coraz sprawniejszych wyszukiwarek często nie
jesteśmy w stanie odszukać żądanej informacji. Protokół HTTP działa w architekturze klient/serwer
i używa standaryzowanego adresu URL (ang. Uniform Resource Locator). Adres URL ma postać
http://domena/plik lokalny. URL jest postacią generycznego adresu URI (ang. Uniform Resource
Identifier). Problem z adresami URL jest taki, że jeśli materiału, który nas interesuje nie ma pod
adresem URL, co wynika z częstych zmian lokalizacji materiału, adres taki jest bezużyteczny.
System adresowy URL jest bowiem związany z lokalizacją serwera, na którym znajduje się zasób, a
nie z identyfikatorem materiału. W3C pracuje nad schematami URN (ang. Uniform Resource
Name) w celu standaryzacji mechanizmów zapewnienia trwałości i integralności (materiał jest
autentyczny i nie zmieniony) oraz niezawodności. Są to adresy, które dają gwarancję znalezienia
materiału (gwarancja trwałości, ang. persistence). Schemat RDF (ang. Resource Description
Framework) specyfikuje rejestrację usług rozpoznania adresów (ang. „resolution”). Prace nad URN
trwają od lat, ale wdrożenia ciągle są odległe.
Zbadano trwałość URL dla pewnej liczby czasopism on-line [1]. Procent aktualnych odsyłaczy
(link) wyniósł 67% dla protokołu HTTP i 31% dla FTP. Półokres zaniku URL wynosi 44 dni.
Widać więc, że dotychczasowy system zarządzania informacją w Internecie jest mało użyteczny,
szczególnie w przypadku bibliotek cyfrowych. Z uwagi na ten fakt środowiska decydujące o
przyszłości Internetu (główny udział w tej inicjatywie miał Robert E. Kahn) powołały w USA
Korporację Inicjatyw Badawczych, Corporation for National Research Initiatives, CNRI
(www.cnri.net). Jest to organizacja not-for-profit promująca strategiczne inicjatywy w dziedzinie
informacyjnych technik sieciowych i wspomagająca W3C w rozwoju najbardziej zaawansowanych
zastosowań.
CNRI współpracuje z The International DOI Foundation (IDF) nad rozwojem systemu
identyfikacji obiektów cyfrowych (Digital Object Identifier System [2]), standardu identyfikacji
treści cyfrowej dla wydawców, zarządców oraz bibliotekarzy informacji cyfrowej przy
wykorzystaniu CNRI Handle System [5] (nie będziemy tłumaczyć na język polski tego wyrażenia)
jako technologii do implementacji tego celu. Celem jest wdrożenie Handle System jako
zmodyfikowanego URN.
Jednocześnie CNRI i IDF stworzyły Digital Object Architecture i zaimplementowały kluczowe
składniki tej architektury w dwóch pilotażach w instytucjach amerykańskich, jednym w the
Copyright Office a w drugim w Bibliotece Kongresu Amerykańskiego (Library of Congress) w
ramach National Digital Library Program.
ZAŁOŻENIA SYSTEMU IDENTYFIKACJI I DOSTĘPU DO OBIEKTÓW
CYFROWYCH
Działania CNRI i IDF doprowadziły do tego, że IETF (Internet Engineering Task Force)
zamierza wprowadzić Handle System [5], ogólny schemat dostępu do obiektów cyfrowych w
środowisku rozproszonym. System ten wprowadza uniwersalną przestrzeń adresową oraz znaczniki
„handle” dostępu do informacji o następujących cechach:
→
→
→
→
→
→
→
→
globalna unikatowość,
trwałość,
wielokrotność informacji,
rozszerzalna przestrzeń adresowa,
oparcie o UNICODE 2.0,
rozproszony model usług i zarządzania,
zapewnienie bezpieczeństwa i wartości intelektualnych treści,
efektywny tryb wyszukiwania.
DOI – (digital object identifier) – identyfikator obiektu cyfrowego - jest stałym identyfikatorem
przypisanym do pliku lub dokumentu internetowego. Tak więc nawet, gdy zmieni się adres
internetowy tego dokumentu, użytkownicy przekierowani zostaną na adres aktualny. Jako adresu
dokumentu używa się adresu centralnie zarządzanego katalogu oraz identyfikatora dokumentu.
System nadawania identyfikatorów opracowany został przez Stowarzyszenie Wydawców
Amerykańskich (Association of American Publishers) przy współpracy z CNRI i jest obecnie
administrowany przez międzynarodową fundację - International DOI Foundation.
Skrót DOI może oznaczać zarówno identyfikator cyfrowy, jak też całą architekturę systemu
zapewniającego rozpoznawanie i zarządzanie identyfikatorami.
System identyfikatorów obiektów cyfrowych (DOI) określić można jako schemat
przekierowywania zapytań internetowych poprzez centralnego nadzorcę. Obecnie istnieje jeden
centralny katalog zarządzany przez Fundację DOI, jednak przewiduje się powstanie wielu tego typu
katalogów zarządzanych np. przez duże korporacje.
Przykładowy identyfikator ma następującą postać:
doi:10.1002/ISBNJ0-471-58064-3
W przykładzie tym, oznaczenie doi jest identyfikatorem przestrzeni nazw (nid), natomiast ciąg
10.1002/ISBNJ0-471-58064-3 jest specyficznym ciągiem w tej przestrzeni (nss). Pierwszy człon
ciągu (prefiks) – ”10.1002” – oznacza katalog ( samo „10” oznacza DOI), a po znaku „/” następuje
dalsza część identyfikatora. W tym przypadku numer ISBN (International Standard Book Number)
określa konkretną książkę wydaną przez określonego wydawcę, natomiast ostatnia cyfra – ”3”
oznacza specyficzną część lub rozdział książki.
Identyfikator DOI będzie skojarzony z odpowiednią stroną WWW lub adresem URL w
katalogu. Aby umieścić odnośnik do dokumentu na stronie internetowej należy odwoływać się do
następującego adresu URL:
http://www.doi.org/10.1002/ISBNJ0-471-58064-3
gdzie ”www.doi.org” jest adresem jedynego jak na razie administratora katalogów
identyfikacyjnych. Użytkownik klikając na tym odnośniku zostanie połączony ze stroną katalogową,
która z kolei zlokalizuje i zwróci adres URL związany z konkretnym identyfikatorem DOI. Przy
założeniu, że katalog jest aktualny, zarówno właściciel strony jak i użytkownik mogą mieć
pewność, że zwrócony zostanie adres najświeższej strony.
Architektura systemu odwołań do obiektu cyfrowego przedstawiona jest na Rys. 1. Użytkownik
klikając na odsyłacz DOI na stronie internetowej nie musi wiedzieć gdzie znajduje się szukany
obiekt, jego przeglądarka łączy się z serwerem DOI, uzyskuje adres internetowy skojarzony z
identyfikatorem i następnie łączy się ze wskazanym adresem.
1. Wysłanie
zapytania DOI
Komputer
użytkownika
z
przeglądarką
3. Uzyskanie
informacji o obiekcie
2. Przekierowanie
Biblioteka lub wydawca
zapytania do biblioteki
/brama
lub dostawcy
Serwer DOI
Rejestr
Identyfikatorów DOI
Informacja o obiekcie
Rys. 1. Architektura systemu odwołań do obiektu cyfrowego
INFORMACJE STANDARYZACYJNE
Składnia DOI jest opisywana przez standard NISO (National Information Standards
Organisation USA) w dokumencie: ANSI/NISO Z39.84-2000 Syntax for the Digital Object
Identifier, gdzie ANSI oznacza American National Standards Institute.
W opracowywanym przez CNRI Handle System do opisu identyfikatorów zamiast określenia
handle używane jest DOI. Obydwa te terminy są zgodne z dokumentem IETF RFC 1737 Functional
Requirements for Uniform Resource Names.
Handle System jest otwartą specyfikacją opisywaną przez następujące dokumenty:
→ Internet Draft -- "Handle System Overview" zgłoszony do IETF w czerwcu 1999
zaktualizowany w lutym 2000,
→ Internet Draft -- "Handle System Namespace and Service Definition" zgłoszony do IETF w
lipcu 1999, zaktualizowany w lutym 2000.
Dokumenty te są zgodne z RFC 2026 - Internet Standards Process, rozdział 10, „Intellectual
property rights”.
System DOI jest oparty na Handle System i używa go do przechowywania i zarządzania
cyfrowymi identyfikatorami obiektów. Handle System zapewnia globalny system nazewnictwa,
który umożliwia każdej lokalnej przestrzeni nazw na przyłączenie się do globalnego i wspólnego
systemu nadawania nazw przez uzyskanie unikatowego znacznika (ang. handle). Lokalne nazwy i
ich powiązania pozostają nienaruszone po dołączeniu się do globalnego Handle System. Każde
odwołanie do lokalnego zasobu może być obsłużone przez interfejs (proxy) komunikujący się z
Handle System, który potrafi zidentyfikować nazwy lokalne.
Handle System definiuje hierarchiczny model usługi. Najwyższy poziom zawiera pojedynczą
globalną usługę znaną jako Global Handle Registry [6] pozwalającą na zarządzanie przestrzeniami
nazw znaczników, natomiast niższe poziomy zawierają wszystkie pozostałe usługi handle (usługi
lokalne).
Warto porównać Handle System z innymi usługami internetowymi realizującymi identyfikację
obiektów:
→ DNS (Domain Name System) jest chyba najbardziej popularnym systemem nadawania nazw
zasobom internetowym. Zapewnia on mechanizm nazywania zasobów w taki sposób, że ich
nazwy są mapowane na adresy IP i dostępne przez różne komputery, sieci i rodziny
protokołów w Internecie. System jednak ten nie nadaje się do zaimplementowania w nim
globalnego systemu nazewnictwa z powodu zbyt dużego znaczenia nazw dla rutingu w
sieciach lokalnych, oraz sposobu zarządzania. Jest to system nieskalowalny i nie jest
możliwe przypisanie kilku zasobów do jednej nazwy. Nazwy DNS są zwykle przydzielane
przez administratorów sieci lokalnych bez żadnego zabezpieczenia nazw, oraz bez żadnych
udogodnień do przydzielania tych nazw dla innych osób. Handle System posiada
rozproszoną architekturę, usługi i zarządzanie. Handle System został od początku
zaprojektowany do obsłużenia systemu nadawania nazw dla wielkiej ilości elementów i
zarządzania nimi przez nazwy. Model danych Handle System pozwala kontrolować dostęp
na każdym z poziomów danych. Każdy handle może mieć dodatkowo zdefiniowanego
administratora, który będzie zarządzał danymi przez protokół uwierzytelniający.
→ Usługi katalogowe X.500/LDAP (Lightweight Directory Access Protocol). X.500 jest
protokołem zdefiniowanym do zapewniania usług typu “white pages” i służy głównie do
szukania danych osobowych. Zapewnia hierarchiczną strukturę danych i mechanizmy do
wyszukiwania. Protokół LDAP jest klientem X.500 możliwym do zaimplementowania na
prostszym sprzęcie nie wymagającym znacznej ilości zasobów i mocy obliczeniowej.
Podstawową różnicą między usługami katalogowymi, a Handle System jest możliwość
przeszukiwania danych i przez to większa złożoność w usługach katalogowych.
→ URN (Uniform Resource Names). Standard ten definiuje składnie, mechanizmy
identyfikacji, oraz procedury rejestracji przestrzeni nazw dla identyfikatorów. Jest on
przeznaczony głównie do obsługi wielokrotnych identyfikatorów oraz systemów
identyfikacji i dostępu do danych. Handle System jest wersją URN, przeznaczoną dla bardzo
specyficznych danych i modelu usług oraz protokołem zapewniającym identyfikację nazw
oraz administrację.
DZIAŁANIE SYSTEMU IDENTYFIKATORÓW CYFROWYCH
Aby móc korzystać z globalnego systemu identyfikacji wystarczy zainstalować plug-in do
przeglądarki, dzięki któremu, przeglądarka będzie identyfikowała adresy DOI zgodnie z protokołem
Handler. Dostępny obecnie plug-in obsługuje jedynie przeglądarki Netscape i Microsoft Internet
Explorer.
Do tworzenia własnych bibliotek elementów, opisywanych przez identyfikatory cyfrowe należy
zainstalować Java Development Kit konieczny do działania platformy Java, Handle Server oraz
Handle System Client Library. W trakcie instalacji konieczne okaże się uzyskanie własnego
numeru identyfikacyjnego, który zostanie przydzielony po przesłaniu pod odpowiedni adres, pliku
wynikowego jednego z kroków konfiguracji. Po zainstalowaniu pełnej wersji serwera użytkownik
uzyska możliwość tworzenia własnych znaczników (handle) do usług (WWW, FTP czy poczta
elektroniczna).
Zasada działania systemu:
1. Użytkownik uzyskuje identyfikator żądanego elementu ze strony internetowej, CD-ROMu
lub dowolnych materiałów reklamowych, wpisuje go w przeglądarce internetowej (lub
innym dedykowanym programie) i wysyła do odpowiedniego serwera.
2. Serwer wyszukuje identyfikator DOI w tablicy gromadzącej identyfikatory, odczytuje
skojarzony adres internetowy i wysyła go do użytkownika.
3. Przeglądarka użytkownika wysyła zapytanie pod adres otrzymany od serwera DOI.
W większości przypadków DOI będzie odnośnikiem na stronie HTML zachowującym się tak
samo jak tradycyjny odsyłacz internetowy. Każdy klient zna lokalizację lub ma kopię globalnego
systemu rejestracji, który przechowuje globalne informacje na temat kluczy publicznych. Na
rysunku 2 pokazano przykładową stronę internetową wykorzystującą znaczniki DOI, strzałkami
zaznaczono odsyłacz DOI na stronie oraz obiekt docelowy na pasku statusu przeglądarki.
Rys. 2. Odsyłacz DOI (strzałka) na stronie HTML
Sposób identyfikacji i dostępu do obiektów cyfrowych pokazany jest na rysunku 3. Klient (np.
przeglądarka internetowa) wysyła żądanie adresu związanego z identyfikatorem do serwera proxy w
swojej sieci lokalnej. Serwer proxy najpierw sprawdza czy identyfikator nie odnosi się do zasobów
lokalnych, a następnie przesyła żądanie do systemu rejestracji i przetwarzania znaczników. System
ten odpowiada wysyłając przez serwer proxy do klienta odpowiedni adres Internetowy. Po
uzyskaniu adresu klient łączy się z nim bezpośrednio i uzyskuje żądany zasób.
Globalny system
rejestracji i
rozpoznawania
znaczników handle
DOI: 10.789/abc
10.123/789=http://local/abc.html
Sieć lokalna
Zasoby lokalne
Proxy
http://www.pub.com/abc.html
DOI: 10.789/abc
http://www.pub.com/abc.html
www.pub.com
DOI: 10.789/abc
abc.html
Klient lokalny
Rys. 3. Sposób identyfikacji i dostępu do obiektów cyfrowych
Rysunek 4 przedstawia sposób interpretacji znacznika handle. Znacznik może być skojarzony z
kilkoma adresami URL (wybór któregoś z nich będzie odbywał się według zdefiniowanego sposobu
np. odległość serwera ). Może być również powiązany z systemem DLS (Digital Library System)
lub z dowolną zestandaryzowaną usługą, co otwiera możliwości w korzystaniu z nowych usług
internetowych.
Handle
Typ danych
10.1004/abcde123456
Dane handle
URL http://www.pub1.com
URL http://www.pub2.com
DLS loc/repository
Rozszerzalne typy danych
Identyfikator zawartości
(nazwa)
XYZ 1010101011000
Usługi cyfrowe
Rys.4. Sposób interpretacji znaczników
ZASADY TWORZENIA METADANYCH W DOI
Metadane [3] (wg definicji Duane Harbin art. http://www.atla.com/refdes/diktuon/dikt0299.html)
są to uporządkowane, strukturalne dane opisujące inne dane. Wszelkiego rodzaju indeksy czy
katalogi są doskonałym przykładem metadanych. Podstawowym ich przeznaczeniem jest
przekierowywanie użytkownika do danych właściwych. Jednak znaczenie metadanych może być
daleko szersze i na przykład opisywać one mogą pewien specyficzny format pliku – wskazując na
przeznaczenie każdego bitu danych w pliku oraz jego kontekst. Tak więc w ogólności metadane
należy uznać jako zbiór informacji określających zawartość.
Grupowanie obiektów czy informacji jako spełniających te same kryteria może być
przeprowadzane w różny sposób, zależnie od potrzeb. Dla przykładu jedno wydrukowane wydanie
czasopisma (wielotysięczny nakład) może być w pewnych przypadkach traktowane jako pojedynczy
egzemplarz. Odwoływanie się do konkretnego zdjęcia na określonej stronie czasopisma, traktowane
będzie tak samo jak odwołanie do całego wydania, natomiast aby przeczytać czasopismo trzeba
sięgnąć po ściśle określoną kopię wersji drukowanej. Tak więc jeden identyfikator nie może
obsłużyć wszystkich zastosowań chociażby z tego względu, że grupowanie może następowac po
różnych elementach (raz identyfikować klasę a raz określony element klasy). Do tego potrzebna jest
cała sieć identyfikatorów, a związki pomiędzy nimi wyrażone muszą być poprzez odsyłacze.
Metadane określają właśnie element w wymagany sposób. Nie wystarczy więc przypisać
identyfikatora do obiektu bez określenia czym jest ten obiekt i jakiego jest on typu, lecz wskazać te
informacje w elemencie stowarzyszonym – jako metadane. Metadane powinny być utworzone w
sposób nieskomplikowany (pozwalający na łatwe odczytywanie i operowanie poszczególnymi
elementami) oraz zgodny z przyjętym modelem, aby zapewnić poprawne wyrażanie związków
pomiędzy poszczególnymi elementami metadanych. Każdy schemat metadanych posiadać musi
określoną liczbę elementów, określone z góry nazwy elementów oraz znaczenia poszczególnych
elementów. Typowo semantyka opisuje rodzaj zawartości i kontekst, fizyczne atrybuty, typy (np.
tekst lub obraz, mapa lub model), formy (np. kopia drukowana, plik w wersji elektronicznej) itp.
Niektóre popularne schematy metadanych to np.:
→ Dublin Core,
→ AACR2 (Anglo-American Cataloging Rules),
→ GILS (Government Information Locator Service).
Kiedy używany będzie odpowiedni identyfikator obiektu cyfrowego, stowarzyszone z nim
metadane będą włączane do informacji o zasobach. Kluczowym zastosowaniem metadanych jest
wskazywanie, czy określony element spełnia warunki poszukiwania poprzez udostępnienie w
formie łatwej do odczytania podstawowych informacji o elemencie. Informacje opisowe nie mogą
być przenoszone poprzez sam identyfikator, natomiast są właśnie zawarte w stowarzyszonymi z nim
metadanymi. Pozwala to na sprawdzenie czy wybrany element jest żądanym bez potrzeby
wchodzenia w bezpośrednią zawartość. Dla przykładu przy wyszukiwaniu książek poprzez numery
ISBN przydatne będą stowarzyszone dane jak np. tytuł czy nazwisko autora. Pomimo istnienia
standardów identyfikatorów stowarzyszonych z metadanymi, nie zawsze zapewniają one strukturę
wymaganą dla potrzeb systemu i trwają jeszcze dyskusje nad koniecznością wyspecyfikowania
nowych standardów zapewniających prawidłowe rozpoznawnie i identyfikację metadanych.
Identyfikator musi deklarować metadane, które w sposób nieskomplikowany będą definiowały
identyfikowany element, a z drugiej strony aby element mógł być rozpoznany na podstawie
opisujących go metadanych. Nie jest wymagane aby przechowywać metadane wewnątrz systemu
DOI; wystarczy, że poprzez DOI określony zostanie wskaźnik do deklaracji metadanych.
Jest jeszcze wiele innych zastosowań metadanych. Mogą one dla przykładu zawierać małą
część informacji (np. abstrakt), dostepną za darmo, przeznaczoną jako reklama kompletnego
elementu o dostępie chronionym (cały artykuł). Poza tym posługiwanie się metadanymi pozwala
użytkownikowi bardziej precyzyjnie określić rodzaj zawartości, której poszukuje. Metadane
pozwalają również zidentyfikować, czym jest to co użytkownik wyszukał w sieci oraz określić
związki pomiędzy poszczególnymi częściami zawartości.
Wprowadzenie metadanych do systemu DOI ma na celu m.in.:
→ ochronę praw autorskich,
→ rozpropagowanie systemu,
→ budowanie usług dodanych opartych o DOI,
→ wprowadzenie pętli zwrotnej do systemu DOI pozwalającej odszukać określony DOI,
→ uzupełnianie istniejących usług wyszukiwania i indeksowania (A&I – Abstracting and
Indexing).
Wykorzystanie metadanych w systemie pozwoli także na kontrolę efektywności wykorzystania
identyfikatorów oraz wprowadzenie zarządzania jakością w przyszłości. Na rysunku 5 pokazano
sposób gromadzenia i przepływ metadanych.
DOI i Metadane
Lista
prefixów
Nośniki
CD
Metadane
Rejestracja
Rejestracja
usług
usług
DOI
DOI
Dane handle
Metadane
DOI
Inne serwisy
danych
Dodatkowe
indeksy,
filtry,
zapytania
Handle System
Rys. 5. Gromadzenie i przepływ metadanych
PODSUMOWANIE
Internet w większości zawiera nieuporządkowaną informację. Dostęp poprzez URL nie spełnia
wymagań korzystania z bibliotek cyfrowych. System DOI (Handle System) posiada wiele
przydatnych cech zwiększających funkcjonalność Internetu. Można mieć nadzieję, że stanie się
internetowym ISBN XXI wieku.
W pierwszej kolejności z systemu identyfikatorów obiektów cyfrowych korzystają największe
oficyny wydawnicze, które wymagają śledzenia położenia tysięcy dokumentów, w tym wielu
osiągalnych poprzez sieć. Zmiana położenia plików, przy tak wielkiej liczbie dokumentów
powodowałaby konieczność ciągłej zmiany odnośników na stronach internetowych danego
wydawnictwa lub wielokrotne wyświetlanie strony informującej o przekierowaniu w przeglądarce
użytkownika. Wykorzystanie systemu DOI pozwala aktualizować jedynie centralny katalog i nie
stwarza konieczności dokonywania jakichkolwiek zmian na stronach internetowych w związku ze
zmianą położenia plików docelowych. „Handle System” ułatwi wprowadzenie wielu usług np.
globalnego cache’u, typu zaimplementowanego przez firmę Akamai. Będzie on miał duże znaczenie
dla trybu korzystania z baz danych. Niestety Handle System rozwija się niezależnie od systemów
typu Akamai, jak również systemów, zarządzania archiwizacji i indeksowania danych
multimedialnych MPEG-7.
Implementacja systemu DOI pociągnie za sobą pewne koszty:
→ rozwój i standaryzacja systemu,
→ utrzymanie infrastruktury systemu rejestracji i identyfikacji zasobów, rejestracji metadanych.
Koszt ten powinien być ponoszony przez wydawców a nie przez użytkowników końcowych,
chociaż może być na nich przenoszony w postaci opłat za korzystanie z treści.
BIBLIOGRAFIA
[1] Ford&Harter College and Research Libraries, lipiec 1998
[2] Norman Paskin „Slide presentation: Digital Object Identifier”,
http://www.doi.org/about_doi/index.htm, luty 1999
[3] Norman Paskin "Digital Object Identifier: implementing a standard digital identifier as the
key to effective digital rights management",
http://www.doi.org/doi_presentations/aprilpaper.pdf, kwiecień 2000
[4] Norman Paskin "The DOI Handbook Version 0.4.1” ,
http://www.doi.org/handbook_2000/index.html, czerwiec 2000
[5] Sam X. Sun, Larry Lannon: “Handle System Overview”, http://www.ietf.org/internetdrafts/draft-sun-handle-system-04.txt, luty 2000
[6] Sam X. Sun, Larry Lannon: “Handle System Namespace and Service Definition”,
http://www.ietf.org/internet-drafts/draft-sun-handle-system-02.txt , luty 2000

Podobne dokumenty