EBIB 
Nr 4/2002 (33), Standardy i organizacja. Artykuł
 Poprzedni artykuł Następny artykuł   

Tekst recenzowany


 
Rozmiar: 77 bajtów Rozmiar: 77 bajtów Rozmiar: 77 bajtów Rozmiar: 77 bajtów


Marek Nahotko
Energoprojekt - Kraków SA

Stare i nowe standardy opisu dokumentów elektronicznych

Rozmiar: 77 bajtów Rozmiar: 77 bajtów
Rozmiar: 45 bajtów

Środowisko sieci rozległych, w tym głównie Internet, przeżywa wciąż okres bardzo gwałtownego rozwoju. Prawie każdego roku pojawiają się nowe narzędzia służące lepszej wymianie informacji, wiele innych odchodzi w zapomnienie. Jak na tym tle wygląda sytuacja narzędzi służących opracowaniu (opisowi) zasobów internetowych? Pytanie to jest tym bardziej istotne, że - jak wiadomo - nie sprzęt ani oprogramowanie, ale DANE są najcenniejszą częścią każdego systemu komputerowego.

Pomiędzy bibliotekarzami zajmującymi się opracowaniem zasobów dokumentów elektronicznych, szczególnie internetowych, prowadzone są dyskusje o możliwości zastąpienia tradycyjnych formatów opisu nowymi, zwanymi metadanymi. Z jednej strony, dla bibliotekarzy szokujące wydają się głosy mówiące o potrzebie odejścia od stosowania tradycyjnych formatów, takich jak np. MARC 21; wskazują oni na fakt istnienia milionów rekordów zapisanych w tym formacie. Z drugiej strony, pilna potrzeba stworzenia zaawansowanych narzędzi pozwalających na dostęp do zasobów on-line i bardzo wysokie koszty opracowania zasobów internetowych przy pomocy tradycyjnych formatów powoduje zainteresowanie nowymi formatami, takimi jak np. Dublin Core.

Przyjrzyjmy się zatem, w jaki sposób opracowuje się zasoby internetowe przy pomocy narzędzi tradycyjnych (format MARC) i nowszych, wciąż rozwijanych (Dublin Core).

Format MARC - czy jeszcze żywy?

Kamieniami milowymi wyznaczającymi kierunki rozwoju sposobów reprezentacji informacji bibliograficznych i bibliotecznych w ubiegłym wieku były: struktura rekordu MARC, Library of Congress Subject Headings (LCSH) oraz baza danych WorldCat. Można je uznać za symbole dokonań ówczesnej standaryzacji struktury i postaci danych oraz swoistej globalizacji informacji bibliograficznej.

Biblioteki na całym świecie używają formatu MARC do wymiany danych już od 30 lat. W tym czasie w technice komputerowej dokonał się olbrzymi postęp, ale dane wciąż są zapisywane w tym samym formacie. Czy rzeczywiście w tym samym? MARC przez cały ten czas ewoluował, jego historię prześledzić można porównując kolejne jego wersje. Pojawienie się dokumentów elektronicznych pociągnęło za sobą także kolejne zmiany.

Modyfikacje formatu MARC, służące jego dostosowaniu do potrzeb opisu dokumentów elektronicznych poszły w dwóch kierunkach. Są to:

1. Dostosowywanie struktury formatu przez tworzenie nowych pól. Pierwszym sposobem jest modyfikacja struktury samego formatu. Często powoływanym przykładem jest tu utworzenie w latach dziewięćdziesiątych pola 856 (lokalizacja elektroniczna), zanim jeszcze całkowicie wdrożono koncepcję URL. W polu tym wpisuje się m. in. adres pozwalający na utworzenie linku od opisu bibliograficznego do elektronicznego dokumentu dostępnego zdalnie. Równie istotną rolę odgrywa w opisie dokumentu elektronicznego pole 256 (rodzaj i wielkość dokumentu elektronicznego). W polu tym dokonuje się najogólniejszego podziału tych dokumentów na trzy grupy: dane, program, dane i program, a także podaje się wielkość dokumentu. Typ dokumentu identyfikowany jest w etykiecie rekordu. W elemencie 06 etykiety (Leader) umieszcza się jednoliterowy kod. W przypadku plików komputerowych jest to kod "m", a ponieważ wybór kodu w polu etykieta/06 określa typ pola 008 (dane kontrolne, pole stałej długości), wybranie kodu "m" w etykieta/06 oznacza, że 008 identyfikuje pliki komputerowe, a 008/26 zawiera kod rodzaju pliku komputerowego. W wypadkach, gdy źródło nie zostało uznane za plik komputerowy (tzn. nie posiada kodu "m" w etykieta/06), można dodać pole 006 (dane kontrolne) zawierające informację dotyczącą aspektu pliku komputerowego, w szczególności rodzaj pliku komputerowego (006/09). Zauważmy, że pole 007 (forma fizyczna dokumentu) jest obowiązkowe w przypadku, gdy formą fizyczną źródła jest plik komputerowy. Pole to zawiera informacje określające cechy fizyczne opisywanego dokumentu.

W strefie uwag pole 538 (wymagania systemowe i tryb dostępu) wykorzystywane jest do określenia wymagań systemowych i trybu dostępu dokumentu elektronicznego. Podaje się tu takie informacje, jak: nazwa, model komputera, wielkość pamięci, nazwa systemu operacyjnego, oprogramowanie (w tym język programowania), urządzenia peryferyjne, a w przypadku dokumentu dostępnego on-line także informacje o dostępie zdalnym do dokumentu.

2. MARC a SGML i XML. Na początku lat dziewięćdziesiątych XX wieku rozpoczęto prace nad wykorzystaniem SGML do odwzorowania struktury danych bibliograficznych w formacie MARC. Efektem ich było powstanie MARC DTD[1]. W końcu roku 1995 prace te podjęte zostały także przez Library of Congress, gdzie w tym celu powołano specjalny zespół, który po intensywnych dyskusjach utworzył zestaw ogólnych wymagań i wskazówek dla stworzenia DTD. W połowie 1996 roku powstała pierwsza testowa wersja DTD. Dwa lata później przygotowano oprogramowanie służące konwersji danych pomiędzy MARC21 i SGML.

O ile SGML można traktować jako język programowania wysokiego poziomu, to DTD może być uważane za program napisany w tym języku. MARC DTD zawiera ponad 20 000 wierszy kodu i odwołuje się do 12 elementów zewnętrznych.

    Oto przykładowy fragment formatu MARC (pole 245) i jego odpowiednika określonego w MARC DTD w SGML przejęty z pracy Sally McCallum pt. SGML/MARC Mapping (patrz bibliografia załącznikowa, poz. 3). Pole 245 w MARC i SGML wyglądają następująco:
  • MARC:
    245 10 $aSGML : $b an author's guide to the standard generalized markup language / $c Martin Bryan
  • SGML:
    <mrcb245 i1="1" i2="0"/><mrcb245-a>SGML :</mrcb245-a> <mrcb245-b>an author's guide to the standardized generalized markup language /</mrcb245-b>
    <mrcb245-c>Martin Bryan</mrcb245-c>
    Od 1998 roku trwają prace nad konwersją rekordów MARC do XML. Wymienić tu można takie projekty jak:
  • Medlane realizowany przez Lane Medical Library (http://xmlmarc.stanford.edu/), mający na celu konwersję rekordów MARC do XML w celu integracji z innymi zasobami Web,
  • francuski projekt BiblioML (http://culture.fr/BiblioML), w którym konwertowany jest UNIMARC do XML,
  • projekt Logos Research Systems pozwalający na obustronną konwersję MARC - XML (http://www.logos.com/marc).

Nowe schematy metadanych - Dublin Core

Metadane to dane o danych. Jako takie zawsze były w sferze zainteresowania bibliotekarzy - opisy katalogowe czy bibliograficzne to właśnie przykłady metadanych. Współcześnie przyjęło się jednak określanie tym terminem opisów dokumentów elektronicznych, szczególnie dostępnych zdalnie poprzez sieci rozległe. Zatem opisy w MARC przedstawione w poprzednim rozdziale można nazwać metadanymi.

Oprócz wcześniej używanych formatów powstały także nowe, przygotowane z myślą o opisie zasobów elektronicznych. Obecnie istnieją ich setki, jednak najbardziej znanym jest Dublin Core Metadata Element Set, w skrócie DCMES, zarządzany przez Dublin Core Metadata Initiative (DCMI - http://dublincore.org/). Jest to zestaw 15. elementów danych (zob. polskie tłumaczenie - http://ebib.oss.wroc.pl/standard/dc.html), uważanych przez jego twórców za przydatne do opisu dokumentów elektronicznych. Semantyka tych elementów została ustalona na zasadzie konsensusu przez międzynarodową grupę interdyscyplinarną złożoną ze specjalistów z zakresu bibliotekarstwa, informatyki, muzealnictwa, archiwistyki i innych dziedzin pokrewnych. Każdy element DC jest opcjonalny i powtarzalny, mogą one być także wpisywane w dowolnej kolejności.

Dążeniem twórców DCMES było uzyskanie efektu prostoty stosowania tego formatu - jego użytkownikami (w tym twórcami opisów) mają być autorzy dokumentów elektronicznych. Szybko jednak okazało się, że 15 elementów to za mało i podjęto decyzję o ich kwalifikowaniu, czyli uszczegółowianiu ich znaczenia przez dołączanie kwalifikatorów (zob. tłumaczona lista kwalifikatorów - http://ebib.oss.wroc.pl/standard/dcq.html). Jest również częstą praktyką tworzenie zestawu kwalifikatorów lokalnie, dzięki czemu DCMES może być dostosowany do indywidualnych potrzeb. DCMI opracowało standardowy sposób "kwalifikowania" elementów DC przy pomocy różnych rodzajów kwalifikatorów.

    Istnieją dwa rodzaje kwalifikatorów:
  • Kwalifikatory uszczegóławiające elementy (zawężają lub uszczegółowiają znaczenie elementu). Uszczegółowiony element posiada znaczenie niekwalifikowanego elementu, jednak w bardziej ograniczonym zakresie. Klient (oprogramowanie) nie rozumiejący znaczenia kwalifikatora powinien go pominąć i traktować element metadanych jako niekwalifikowany (szerszy).
  • Kwalifikatory identyfikujące schemat kodowania (identyfikują schematy wspomagające interpretację wartości elementu). Schematami tymi są słowniki kontrolowane oraz formalne notacje lub określenie zasad. Wartość wyrażona przy użyciu schematu kodowania będzie więc znakiem wybranym ze słownika kontrolowanego (np. termin z tablic klasyfikacji lub słownika haseł przedmiotowych) lub ciągiem sformatowanym zgodnie z formalną notacją (np. "2002-03-15" jako standardowe wyrażenie daty). W wypadku, gdy schemat kodowania jest niezrozumiały dla oprogramowania klienta, może on być nadal zrozumiały dla człowieka.

Podczas kwalifikowania elementów Dublin Core stosuje się tzw. zasadę "Dumb-Down", według której klient powinien mieć możliwość ignorowania każdego kwalifikatora i używać opisu w taki sposób, jakby nie był kwalifikowany. Oczywiście takie postępowanie powoduje utratę pewnych szczegółowych znaczeń, jednak pozostała wartość elementu (bez kwalifikatora) musi pozostać poprawna.

Dublin Core jako standard internetowy od początku był pomyślany jako narzędzie do stosowania w HTML, a obecnie trwają prace nad ustaleniem sposobów jego wykorzystania w XML i RDF (http://www.w3.org/TR/PR-rdf-syntax/).

    Od początku tworzenia Dublin Core celem jego autorów było stworzenie formatu, który cechowałyby:
  • Prostota tworzenia i obsługi. Zestaw elementów Dublin Core powinien być możliwie jak najmniejszy i jak najprostszy, aby umożliwić łatwe i tanie tworzenie prostych opisów bibliograficznych nie bibliotekarzom, przy jednoczesnym zapewnieniu efektywnego wyszukiwania tych opisów w środowisku sieciowym.
  • Ujednolicenie zasad tworzenia opisów. Wyszukiwanie informacji w ogromnych zasobach Internetu jest utrudnione przez różnice terminologiczne i używanie różnych zasad tworzenia opisów bibliograficznych. Dublin Core, jeżeli stanie się powszechnie używanym standardem, może pomóc tzw. "cyfrowemu turyście", czyli użytkownikowi nie będącemu specjalistą w zakresie informacji naukowej w zaspokojeniu własnych potrzeb przez udostępnienie jednolitego zestawu elementów, których znaczenie jest powszechnie znane i zrozumiałe.
  • Międzynarodowy zasięg. DCMES został utworzony w języku angielskim, jednak powstało wiele innych wersji językowych (http://dublincore.org/groups/languages/ - related), w tym w takich językach jak fiński, norweski, tajski, japoński, francuski, portugalski, niemiecki, grecki, indonezyjski, hiszpański oraz polski.
  • Rozszerzalność. W celu zrównoważenia potrzeby prostoty opisu zasobów cyfrowych i potrzeby precyzyjnego wyszukiwania, twórcy DC stwierdzili konieczność wprowadzenia mechanizmu służącego rozszerzaniu zestawu elementów DC dla zaspokojenia potrzeb wyszukiwania bardzo zróżnicowanych zasobów dostępnych w Internecie. Oczekuje się, że grupy ekspertów w różnych dziedzinach szczegółowych utworzą i będą administrowały dodatkowymi zestawami metadanych. Należy zapewnić możliwość łatwego przyłączenia elementów metadanych pochodzących z tych zestawów do Dublin Core, aby umożliwić rozbudowę (rozszerzenie) zestawu jego elementów. Taki model pozwala różnym społecznościom na używanie elementów DC w celu tworzenia prostych opisów przydatnych w Internecie, przy jednoczesnym ich wzbogacaniu o elementy przydatne ze względu na zastosowania szczegółowe w ograniczonych obszarach. Tworzone są odpowiednie instrukcje postępowania w tym zakresie.

Twórcy wszystkich formatów metadanych starają się zapewnić sobie możliwość konwersji do DCMES jako powszechnie znanego i stosowanego standardu metadanych. Taka konwersja możliwa jest także pomiędzy Dublin Core a starszymi formatami danych, głównie MARC. Na bazie tych możliwości powstał CORC.

Zastosowanie formatów MARC i Dublin Core

Zanim przedstawiony zostanie projekt CORC, będący przykładem ścisłej koegzystencji obu formatów, spróbujmy przewidzieć przyszłe ich zastosowania w funkcjonujących bibliotekach. Jak ma już to miejsce w wielu bibliotekach, pewne źródła internetowe będą nadal opisywane w formacie MARC i dostępne w katalogu OPAC Zasoby te będą zapewne składały się głównie ze zbiorów kupowanych przez biblioteki, takich jak czasopisma elektroniczne czy bazy danych dostępne zdalnie. Niezbędne będzie uzupełnianie rekordów bibliograficznych danymi dotyczącymi procesów gromadzenia, które muszą być dołączane do nadrzędnego rekordu bibliograficznego. Zatem opisy bibliograficzne zakupionych przez biblioteki zasobów dostępnych w Internecie obecne będą w katalogach komputerowych tych bibliotek.

Inaczej sytuacja wygląda z zasobami Internetu dostępnymi bezpłatnie, takimi jak strony Web organizacji i przedsiębiorstw, wcześniej katalogowanymi w tradycyjnym MARC, dla których zapewne nie będzie już wymagany pełny opis bibliograficzny. Tego typu zasoby są głównym przedmiotem zainteresowania twórców rekordów metadanych zgodnych ze standardem Dublin Core. Podobnie metadane Dublin Core będą włączane do kodu źródłowego dokumentów elektronicznych tworzonych przez same biblioteki. W efekcie nie będzie potrzeby tworzenia list "ważnych linków" na stronach Web, gdyż baza danych rekordów Dublin Core przejmie ich funkcje. Niezbędne wydaje się też tworzenie wspólnych słowników kontrolowanych dla obu typów baz (OPAC w MARC i Dublin Core), gdyż ułatwi to przyszłe jednoczesne wyszukiwania we wszystkich zasobach i łączenie baz danych.

Poniżej, w tab.1, przedstawiono porównanie formatów Dublin Core i USMARC. Zestawienie to pomoże zorientować się w możliwości konwersji tych formatów. Porównanie ma charakter ogólny, nie obejmuje np. kwalifikatorów DC ani pewnych szczególnych przypadków przewidzianych w formacie USMARC.

Tab. 1. Porównanie formatów Dublin Core i USMARC[2] .
Element Dublin Core Etykieta MARC
Tytuł Tytuł (245 $a)
Twórca Nazwa osobowa - hasło główne (100 $a)
Opis rzeczowy Słowa kluczowe niekontrolowane (653 $a)
Hasło przedmiotowe LCSH (650 $a)
Opis Adnotacja wyjaśniająca (520 $a)
Wydawca Wydawca (260 $b)
Współtwórca Nazwa osobowa - hasło dodatkowe (700 $a)
Data Data wydania (260 $c)
Typ Typ / Forma dokumentu (655 $2)
Format Typ formatu elektronicznego (856 $q)
Identyfikator Lokalizacja elektroniczna (856 $u)
Źródło Źródło wprowadzonych danych (786 $n)
Język Uwaga dotycząca języka (546 $a)
Kod języka (041 $a)
Relacja Uwaga dotycząca relacji nieokreślonej (787 $n)
ID relacji nieokreślonej (787 $o)
Miejsce i czas Uwaga ogólna (500 $a)
Własność Warunki wykorzystania (540 $a)

CORC - stare i nowe schematy metadanych

CORC - Cooperative Online Resource Catalog (http://corc.oclc.org/corc) jest jednym z najnowszych projektów OCLC, który zakłada wykorzystanie zarówno MARC, jak DCMES do tworzenia bazy danych o zasobach internetowych wyselekcjonowanych ze względu na wysoką jakość. Po zintegrowaniu zasobów CORC i WildCat system ten ma szansę stać się podstawowym źródłem informacji o publikacjach naukowych w zasobach Web na skalę światową. Pomimo że brak jest obecnie bezpośredniego połączenia WildCat z CORC, to możliwość przeniesienia rekordów z WildCat do CORC nie budzi raczej wątpliwości. Eksport w odwrotną stronę, choć technicznie wykonalny, może napotykać na problemy w przypadku eksportu rekordów wykonanych w Dublin Core. Format MARC jest bardziej ścisły niż Dublin Core, więc importowane rekordy mogą nie posiadać właściwych ograniczników podpól, etykiet pól i elementów pól stałych, typowych dla MARC.

Wymienność danych jest jedną z podstawowych cech systemu CORC. Uczestnicy projektu mogą wprowadzać rekordy zarówno w formacie MARC, jak i Dublin Core. Rekordy te są następnie zapisywane w XML i mogą być przekazywane użytkownikowi końcowemu również w jednym z dwóch formatów.

Pomimo tego, że konwersja elementów kwalifikowanego Dublin Core do pól MARC jest z technologicznego punktu widzenia prostym procesem, wykonywanym szybko i bezbłędnie przez CORC, to jednak różnice w koncepcji pomiędzy dwoma standardami mogą powodować pewne nieporozumienia. Tak się dzieje np. wtedy, gdy element DC.Twórca z części <META> źródła jest konwertowany na pole 100 MARC, a otrzymana nazwa osobowa nie odpowiada używanej notacji AACR2 dla hasła, lub też gdy element DC. WspółtwórcaKorporatywny jest konwertowany do pola 710 nawet wtedy, gdy nazwa instytucji korporatywnej nie jest wykazana w żadnym polu rekordu, co jest wymagane dla rekordów MARC zgodnie z AACR2. Większość twórców zasobów Web, umieszczających w swoich dokumentach metadane, używa standardu DC, natomiast rzadko mają oni jakąkolwiek wiedzę o MARC czy AACR2. DC został specjalnie skonstruowany do tworzenia opisów zasobów internetowych, natomiast pierwsze wydanie AACR przeznaczone było głównie dla materiałów drukowanych, a drugie wydanie wciąż wykazuje silną orientację "bibliocentryczną", dlatego korzystanie z DC do opisu zasobów Web ma wiele zalet. Nie dziwi więc, że Dublin Core jest standardem preferowanym, zarówno z powodu możliwości zastosowania, jak i łatwości użycia, szczególnie przez autorów metadanych, którzy nie katalogują zbiorów ani w ogóle nie są bibliotekarzami.

Jedną z najważniejszych cech CORC jest zdolność do automatycznego tworzenia wstępnego rekordu katalogowego. Jest to możliwe dzięki pobieraniu metadanych znajdujących się w obrębie etykiet <META> samego źródła, jak i zastosowaniu technik sztucznej inteligencji do analizy tekstu źródła: na podstawie tej analizy tworzy się zestaw możliwych słów kluczowych i/lub symboli klasyfikacji Deweya.

W uzupełnieniu do systemu tworzenia opisów w CORC, OCLC zrealizował również projekt systemu służący do tworzenia tzw. "pathfinders" do bazy danych opisów źródeł. Termin ten oznacza rodzaj wykazu podstawowych źródeł warsztatu naukowego danej dziedziny. Zawierają one zazwyczaj spisy podstawowych encyklopedii, czasopism, słowników, wykazów słów kluczowych i haseł przedmiotowych oraz innych tego typu źródeł dostępnych dla użytkownika biblioteki. Taki wykaz jest tradycyjnym odpowiednikiem wielu stron Web, które gromadzą linki wraz z ich krótkim opisem w celu ułatwienia odnalezienia informacji w Web. Biblioteki mogą tworzyć strony Web zawierające standardowe linki i opisy, mogą jednak także dołączyć dynamiczne wyszukiwanie w katalogu CORC, którego wyniki wyświetlane są na stronie. Wyniki wyszukiwań są integrowane i wyświetlane dla użytkownika w formie linków i ich opisów. System ten w CORC ma jeszcze pewne niedogodności wynikające z ograniczenia zakresu opcji formatujących, ale jego dużym osiągnięciem jest umożliwienie podziału obsługi URL pomiędzy wszystkich uczestników CORC. W wypadku, gdy jedna instytucja dokona korekty URL, zmieniane są linki na wszystkich stronach zawierających "pathfinders" we wszystkich innych instytucjach.

Tak jak w poprzednich projektach OCLC, CORC wykorzystuje współpracę między bibliotekami do tworzenia swoich zasobów. Jednym z efektów współdziałania jest możliwość sprostania problemom związanym z naturalnymi w Web zmianami treści i lokalizacji zasobów elektronicznych. Serwis CORC udostępnia prototypowe rozwiązania pozwalające na kontrolę i poprawę URL oraz kontrolę treści dokumentów. Tego typu automatyczna kontrola będzie głównie polegała na wysiłkach podejmowanych wspólnie dla modyfikacji opisów zmieniających się dokumentów opisanych w CORC. Taki efekt osiągnąć można wyłącznie dzięki współpracy na wielką skalę. Po modyfikacji URL lub opisu źródła przez jedną bibliotekę jest ona dostępna automatycznie dla wszystkich bibliotek współpracujących.

Wersja demonstracyjna systemu CORC jest udostępniana pod adresem http://www.oclc.org/corc/learning/demo/

Bibliografia

  1. EDMUNDS, Jeff, BRISSON, Roger. Cataloging in CORC: A Work in Progress [on-line]. [dostęp: 14 marca 2001]. Dostępny w World Wide Web: <http://www.personel.psu.edu/faculty/r/o/rob1/corc/>.
  2. MCCALLUM, Sally. Extending MARC for Bibliographic Control in the Web Environment: Challenges and Alternatives [on-line]. Washington DC: Library of Congress, December 2000 [dostęp: 4 kwietnia 2001]. Dostępny w World Wide Web: <http://lcweb.loc.gov/catdir/bibcontrol/mccallum_paper.html>.
  3. MCCALLUM, Sally. SGML/MARC Mapping [on-line]. February 1997 [dostęp: 4 kwietnia 2001]. Dostępny w World Wide Web: <http://www.columbia.edu/cu/libraries/inside/projects/ sgml/sgmlmarc/lc.status.9702.html>.
  4. NAHOTKO, Marek. Metadane. In EBIB [on-line] 2000, Nr 6(14) [dostęp: 4 kwietnia 2001]. Dostępny w World Wide Web: <http://ebib.oss.wroc.pl/arc/e014-02.html>.
  5. RZOŃCA Irena, SZYLHABEL Krystyna: Dokumenty elektroniczne w systemie APIN. Bibliotekarz 2000 nr 3, s. 2-7
  6. SANETRA, Krystyna. Katalogowanie dokumentów elektronicznych [on-line]. Kraków : Biblioteka Jagiellońska, Luty 1999 [dostęp: 4 lutego 2002]. Dostępny w World Wide Web: <http://phmm.bj.uj.edu.pl/~krystyna/kel.htm>.

Przypisy

[1] DTD - Document Type Definition, zespół reguł służący opisowi klasy dokumentów.

[2] Tłumaczenie etykiet pól USMARC częściowo wg autora artykułu. Przygotowano na podstawie http://www.loc.gov/marc/bibliographic/ecbdhome.html

  Na początek
Rozmiar: 45 bajtów
Rozmiar: 77 bajtów Rozmiar: 77 bajtów Rozmiar: 77 bajtów Rozmiar: 77 bajtów



Stare i nowe standardy opisu dokumentów elektronicznych/Marek Nahotko // W: EBIB Elektroniczny Biuletyn Informacyjny Bibliotekarzy [Dokument elektroniczny] / red. naczelny Bożena Bednarek-Michalska. - Nr 4/2002 (33) kwiecień. - Czasopismo elektroniczne. - [Warszawa] : Stowarzyszenie Bibliotekarzy Polskich KWE, 2002. - Tryb dostępu: http://www.ebib.pl/2002/33/nahotko.php. - Tyt. z pierwszego ekranu. - ISSN 1507-7187

 

Rozmiar: 77 bajtów Rozmiar: 77 bajtów