r»portu dotyczącego przyszłości kontroli bibliograficznej zwracają uwagę * c slosovvuma nowych struktur danych | Library of Congrcss 2008. s 24). MAKr party jest na technice zarządzania danymi sprzed 40 lat. co powoduje. ł.c nic odpowiada spolczesnym standardom tworzeniu oprogramowania. Stosowany jest wyłącznie w bj. ol totek ach. w innych aplikacjach bywa wykorzystywany do przekazywaniu danych. Nowc sposoby wykorzystywania danych bibliograficznych wymagają formatów pozwalających na gromadzenie metadanych, w tym adnotacji (opinii, komentarzy) i danych o wykorzystaniu tworzonych przez ekspertów, użytkowników i narzędzia zautomatyzowane.
Krytyce podlegają także przepisy katalogowania w rodzaju AACR. ISBD czy RDa Według Caren Coyle i Dianę Hillmann. oparte są na nieaktualnej ocenie sytuacji i zamkniętych już celach kontroli bibliograficznej (Coyle. Hillmann 2007). Tymczasem sytuacja w tym zakresie zmieniła się i nadal ulega modyfikacjom: użytkownicy coraz mniej czasu poświęcają opisom bibliograficznym, a coraz więcej wyszukiwaniu pcłnotcksiowc-mu; coraz rzadziej wyszukują, a częściej współpracują w sieciach społecznych, dostarczających im poszukiwanych informacji. W związku z tym potrzebne jest zupełnie nowe spojrzenie na zasady opisu obiektów cyfrowych. Zamiast spisu szczegółowych zasad, uwzględniających w iele wyjątków, niezbędne jest stworzenie warunków zapewniających łatwość i efektywność stosowania tworzonych narzędzi.
Jak piszą wspomniane autorki, wśród bibliotekarzy przyzwyczajonych do tradycyjnych standardów, możliwie pełny i szczegółowy opis katalogowy jest czymś w rodzaju wy idealizowane co celu. Uważają oni. że tego typu opis ma zasadnicze znaczenie dla funkcjonowania nauki i nie zauważają mnożących się problemów, nawet, gdy Google przejmują ich użytkowników. Jakiekolwiek zmiany wychodzące poza linearny model katalogowania, oparty na katalogu kartkowym, związany ze stosowaniem zasad AACR2 czy podobnych, przyjmowane są nieprzychylnie. Bibliotekarze nie wierzą, że prostsze lub mniej ustuktu-ryzowane zasady katalogowania, w znacznie większym stopniu wykorzystujące możliwości współczesnych komputerów, mogą zapewniać usługi na odpowiednim poziomie. W szczególności odrzucane są wszelkie zmiany godzące w zasady ujednolicenia opisów.
Jak wspomniałem, schemat metadanych Dublin Corc Metadata Element Set (DCMES) oowstawał w pewnej opozycji do formatów MARC. W zamyśle twórców schematu Du-,P|jn Corc i zgodnie ze swoją nazwą, zestaw elementów ma stanowić „rdzeń'*, minimum niezbędne do tworzenia opisu dokumentu tekstowego. W razie potrzeby schemat ten może być rozbudowywany i uszczegóławiany przez użytkowników zgodnie z lokalnymi potrzebami. Nie ma elementów obowiązkowych, wszystkie są powtarzalne.
Od czasu powstania pierwszego zestawu elementów DCMES schemat ten uległ znacznej rozbudowie. Utworzenie modelu abstrakcyjnego Dublin Core1 oraz tzw. Singapore Framework2 stanowi poważną jego modyfikację, dzięki której obecnie Dublin Core stanowi podstawę tworzenia opisów dowolnego rodzaju dokumentów. Wymienione prace podstawowe wykorzystane zostały m.in. do budowy profili aplikacyjnych: SWAP (Scholar ly Works Aplication Profile), opartego na modelu FRBR, służącego opisowi prac naukowych3 [Allinson. Johnston. Powell 2007] oraz DCCAP (Dublin Core Collections Application Profile), stosowanego do opisu na poziomie kolekcji4 [Lourdi, Papatheodorou, Doerr 2009].
W Dublin Corc, w porównaniu / MARC, tliibo /organi/owiimi jcnt kontrola aulorytir-na (istnieji) na pr/yklad wykazy terminów umywanych dla elementów lyp i Format), prze/ co bardzo łatwo dwie osoby (u nawet ta sama osoba w większych odstępach czasu) mogą stworzyć dwa, różne opisy tego samego źródłu. Schemat jest jednak wciąż rozwijany (co, jak mówiłem, już wpływa na wzrost stopnia jego skomplikowania), międ/y innymi w kierunku tworzenia zestawów zdefiniowanych wartOki dla wybranych elementów, jako sposobu na zapewnienie jednolitości opisu. Określono na przykład przydatne systemy klasyfikacyjne i inne języki informacyjno-wys/ukiwuwczc, możliwe do zastosowania w elemencie Opis rzeczowy. Oprócz tworzenia zestawów wartości poszczególnych elementów, standaryzacja polega również na tworzeniu reguł kodowania wartości elementów, na przykład dal czy języków.
Znaczenie elementów Dublin Corc może być uszczegółowiane (przez tworzenie tzw kwalifikatorów), co również podlega w pewnym stopniu standaryzacji, gdyż. DCMIM podaje wykazy wyróżnionych przez siebie kwalifikatorów Dla przykładu element Data może być kwalifikowany przez utworzenie bardziej szczegółowych elementów: Data utworzenia, Dala ważności, Data dostępności, Dala wydania, Data modyfikacji i jeszcze innych, według lokalnych potrzeb. Element Opis jest uszczegółowiany prze; utworzenie podelemcntów Abstrakt lub Spis treści, natomiast element Relacja zawiera takie związki, jak Jest wersją, Jest częścią, Zastępuje, Wymaga, Odsyła wraz z relacjami odwrotnymi (typu Jest wersją - Ma wersję).
Powodem częstego wykorzystywania Dublin Core jest możliwość rozwiązywania u jego pomocą kilku istotnych problemów, związanych także z funkcjonowaniem GBC Po pierwsze, potrzebny jest prosty, powszechnie znany format opisu różnego rodzaju zasobów; po drugie, możliwe jest stosowanie wszelkich używanych standardów syntaktyki, od HTML/XHTML przez XML po RDF, dzięki czemu może on być użyteczny w wielu serwisach GBC, w tym w Semantycznym Webie; po trzecie, może być on wspólną podstawą, „najniższym wspólnym mianownikiem" dla semantyki różnych, czasem bardziej obszernych schematów metadanych, co wpływa na ich zdolność do współdziałania. Twórcy tego schematu metadanych starają się także, aby byl on używany w różnych kulturach i językach, promując jego tłumaczenia i tworząc mechanizmy transliteracji.
Obecnie sytuacja w zakresie schematów metadanych stała się nadzwyczaj złożona. Wystarczy wymienić przykłady stosowanych standardów. AACR2/RDA/ISBD, MARC 21, MARCXML, METS, MODS, Dublin Core, czy wiele innych, takich jak ONIX* (stosowany w środowisku wydawców), MIX?n i VRA71 (obiekty graficzne, muzealnictwo), IMS72 (materiały edukacyjne) oraz CSMD (opis badań naukowych i danych z eksperymentów). Ta różnorodność utrudnia zarządzanie, prowadzi do nieporozumień w trakcie implementacji i spowalnia rozwój schematów. Z drugiej strony metadane, służące wyszukiwaniu informacji w Internecie, powstają podczas pelnotekstowego indeksowania, zarówno treści dokumentów, jak i rekordów metadanych, stąd maleje znaczenie ich uslrukturyzowa-nia. Zauważalną tendencją jest konsolidacja schematów metadanych, przez zastosowanie XML jako platformy ułatwiającej współdziałanie, zapewniającej ujednoliconą syntakty-kę, zrozumiałą dla narzędzi wyszukiwawczych. Szansę na unifikację semantyki wiąże się z RDA, w znacznie większym stopniu niż poprzednie standardy uwzględniającym potrzeby opisu obiektów w formatach cyfrowych [Gartner 2008, s. 14). Schematy przedstawione poniżej są przykładem prac służących zwiększeniu indeksowalności metadanych.
M DCMI (Dublin Corc Meladata lniliativc) jest instytucją powołaną dla kierowania pracami nad rozwojem DCMES (http://dublincore.org/).
M ONIine Information eXchange (http://www.editeur.org/onix.html).
70 Meladala for Imagcs in XML Schcma (http://www.loc.gov/standards/mix/).
71 Virtual Resources Association (http://www.vraweb.org/projccls/vracore4/indcx.html).
12 IMS Leming Resourće Meladala Information Model (http://www.imsglobal.org/metadata/index.html).
M Dublin Corc Abstract Model: http://dublincore.org/documents/absiract-modcl/.
M Singapore Framcwork przyjęły został podczas warsztatów DC w Singapurze w 2007 r. Składa się na niego zestaw dokumentów tworzących łącznie Profil Aplikacyjny Dublin Core (DCAP). Dokumenty tc opisują między innymi wymagania funkcjonalne, modele dziedziny i syntaktykę oraz zawierają wskazówki dla użytkowników. Są one pomocne w tworzeniu profili aplikacyjnych i w ich formalnej ocenie.
Zawiera on, oprócz podstawowych elementów metadanych. także elementy dodatkowe, takie jak źródło finansowania badań oraz numer grantu.
* Pozwala na opis kolekcji różnego rodzaju, a także katalogów i indeksów.
1 IO