Przeszukaj Serwis Informacyjny FBC pro

Przeszukaj zbiory FBC

FBC >

Opisywanie obiektów cyfrowych

Do czego służą metadane?

Wprowadzenie

W poniższym rozdziale objaśniono podstawowe terminy związane z problematyką ogólnie pojętych metadanych, omówione zostaną m.in. istniejące schematy metadanych czy słowniki kontrolowane. W dalszej części przedstawione zostaną różne typy metadanych. Dzięki podanej klasyfikacji schematów użytkownik kursu nie będzie czuł się zagubiony w gąszczu akronimów i pojęć, na które z pewnością natrafi w trakcie wyboru standardu metadanych odpowiedniego dla swoich potrzeb. 1
Ilustracja 1. Wizualizacja ponad 105 istniejących standardów metadanych [źródło].
Ze względu na mnogość standardów (por. Ilustracja 1) nie da się opisać ich wszystkich. W niniejszej lekcji opisano ogólnie standardy związane z działaniami Dublin Core Metadata Initiative.

Czym są metadane?

Termin ten przewija się od początku kompendium. Istnieje wiele definicji metadanych, a najpopularniejsza z nich mówi, że metadane są to dane o danych [źródło]. Termin ten stosowany jest w wielu dziedzinach, w tym w informatyce, bibliotekoznawstwie, ale także w wielu innych. W bibliotekach metadane zwykle są stosowane w kontekście opisu obiektu. Opis oznacza ogół informacji, które upraszczają wykorzystanie, wyszukiwanie i zarządzanie danymi zbiorami. Dobrze przygotowane metadane gwarantują, że dany obiekt przetrwa oraz będzie dostępny i użyteczny w przyszłości [źródło]. Biorąc pod uwagę różnorodność zasobów i instytucji, które mogą wymagać metadanych, można sobie wyobrazić jak trudnym zadaniem jest ich tworzenie. Istnieje oczywiście wiele różnych standardów metadanych, na szczęście jednak znajomość wszystkich nie jest niezbędna.

Co można opisać za pomocą metadanych?

Metadane mogą odnosić się do obiektu fizycznego (m.in. książki, czasopisma, dziecięcego rysunku), do ich wersji cyfrowej tj. zeskanowanej książki, rysunku, ale także do materiałów, które powstały w formie cyfrowej. W niektórych przypadkach dość częste jest opisywanie całej kolekcji, a nawet kilku kolekcji. Metadane mogą odnosić się dosłownie do wszystkiego, nawet do samych siebie. Prawdziwe jest stwierdzenie, że czasami trudno odróżnić właściwe dane od metadanych.

Przykłady metadanych

2 Ilustracja 2. Zdjęcie karty katalogowej z tytułem, nazwiskiem autora i sygnaturą miejsca. Zdjęcie autorstwa dfulmer zostało wykorzystane zgodnie z licencją Creative Commons. Każdemu znana jest tradycyjna karta katalogowa (patrz ilustracja 2), która zawiera nazwisko autora, tytuł, kilka haseł rzeczowych oraz sygnaturę. Ten prosty przykład ukazuje jak powszechne i użyteczne są metadane. Są to usystematyzowane informacje, które umożliwiają użytkownikowi (a także programom komputerowym) łatwą ich interpretację. Rozważmy prosty przykład, mamy listę słów kluczowych:Leonardo da Vinci, Mona Lisa, kobieta, obraz. Jest to po prostu lista kilku wyrazów, które opisują pewien obraz. Opis zawiera wszystkie niezbędne informacje, ale nie ułatwia wcale interpretacji np. treści obrazu. Tak naprawdę nie wiadomo, czy któryś z tych wyrazów to nazwisko autora (prawdopodobnie Leonardo da Vinci, ale równie dobrze mogłaby to być Mona Lisa), nie wynika z niego również kogo przedstawia obraz. Jeśli natomiast przyporządkujemy słowa z listy do z góry określonych kategorii, wszystko stanie się o wiele bardziej zrozumiałe:
  • Twórca: Leonardo da Vinci,
  • Tytuł: Mona Lisa,
  • Temat: kobieta, portret.
Oto dlaczego struktura jest tak ważna. Jak wspomniano, istnieje wiele standardów. Jest wiele różnic między nimi, ale większość z nich posiada własną, odrębną strukturę opisu. Standard określa role każdego elementu (kategorii opisu), dlatego nie należy się obawiać o właściwą interpretację danego elementu; czasem standard definiuje również zasady umieszczania wyrażeń lub fraz w danym elemencie opisu. Jeżeli zasady te definiują ograniczoną listę słów, które mogą być użyte w określonej części opisu, mówimy wówczas o stosowaniu tzw. słownika kontrolowanego.
3
Ilustracja 3. Opis produktu ze sklepu internetowego Amazon to przykład dobrze zredagowanych metadanych. Ilustracja 3 prezentuje przykład metadanych dotyczących jednej ze sprzedawanych w sklepie Amazon książek. Dzięki nim użytkownicy sklepu elektronicznego mogą odnaleźć interesujące ich książki. Jednym z podstawowych zadań metadanych jest ułatwianie wyszukania zasobów. Ściśle określona struktura umożliwia twórcom systemów informatycznych zbudowanie zaawansowanych wyszukiwarek, dzięki którym użytkownicy będą mogli odnaleźć to, czego szukają. W przypadku księgarni internetowych dobre opracowanie metadanych jest niezbędne, ponieważ cały dochód zależy od tego, czy użytkownicy znajdą i kupią interesującą ich pozycję.
4
Ilustracja 4. Zrzut ekranu przedstawiający stronę internetową Flikr.com: The Commons. Metadane często uważa się za bardzo skomplikowane zagadnienie, które można zrozumieć jedynie po ukończeniu stosownych studiów lub co najmniej kursu takiego, jak ten. Niekiedy faktycznie tak jest. Przy opracowywaniu bardzo dokładnych metadanych opisowych naprawdę trudno jest określić które słowa powinny zostać użyte i co należy opisać. Im metadane są lepiej opracowane, tym większe prawdopodobieństwo odnalezienia poszukiwanych zasobów. Metadane jednak nigdy nie będą zawierały tak szczegółowej treści jak sam zasób cyfrowy. Metadane oferują zawsze wybiórczy lub uproszczony opis zasobu. Oxford English Dictionary definiuje metadane jako "dane, które funkcjonują na wyższym poziomie abstrakcji". Jeżeli "obraz wyraża tysiąc słów" (albo więcej), oczywiste jest, że opisy tekstowe będą tylko częściowo przekazywały informacje i znaczenie zawarte w zasobie cyfrowym, nie wspominając o wszystkich informacjach, które mogą go dotyczyć (np. historia powstania, powiązania z innymi zasobami [...]" [źródło]. Niekiedy przy tworzeniu metadanych trzeba postępować w sposób wybiórczy, np. opisując XIX-wieczną książkę adresową chciałoby się umieścić chociaż kilka nazw ulic, które zostały w niej wymienione, ale jak dokonać wyboru? Czy jest możliwe, aby umieścić w opisie wszystkie? Z drugiej strony, są sytuacje, w których katalogujący ma do dyspozycji jedynie ograniczoną ilość informacji, szczególnie w przypadku starych fotografii. W jaki sposób zidentyfikować budynki i zabytki, które już nie istnieją? W takim przypadku katalogujący musiałby przeprowadzić prywatne śledztwo, by rozwikłać tajemnicę starej fotografii.
5
Ilustracja 5. Komentarz użytkownika dotyczący prezentowanego zdjęcia to także część metadanych tego zdjęcia. Ilustracja 5 przedstawia jeden z zasobów udostępnianych w ramach “Flickr.com: The commons”. Projekt rozpoczął się w 2008 r. jako wspólna inicjatywa Biblioteki Kongresu i portalu Flickr.com. Biblioteka Kongresu przekazała część zdjęć portalowi Flikr.com i dzięki jego użytkownikom bibliotekarze mogli uaktualnić szereg opisów fotografii znajdujących się w ich kolekcji. Ilustracja 5. pokazuje komentarz jednego z użytkowników, który rozpoznał miejsce przedstawione na zdjęciu. Pozwoliło to pracownikom Biblioteki stworzyć pełniejsze metadane; dodano położenie geograficzne. W niektórych przypadkach użytkownicy również mogą udostępnić obecne zdjęcie danego miejsca. W tej sytuacji także mówimy o metadanych.

Czym są standardy metadanych?

Czym jest standard metadanych? Czym jest schemat metadanych? Co rozumie się pod pojęciem atrybutu/elementu? Zanim omówione zostaną bardziej skomplikowane zagadnienia należy odpowiedzieć na podstawowe pytania. Pojęcie metadanych zostało już zdefiniowane, ale jakie inne ważne pojęcia się z nim wiążą? Jak już wspomniano metadane są to informacje o dobrze określonej strukturze, należy zatem tę strukturę w jakiś sposób określić. Zasady opisujące strukturę opisu nazywane są schematem lub formatem metadanych. Schemat jest zbudowany z kategorii, elementów, pól lub atrybutów (pojęcia te są równorzędne i będziemy je stosować zamiennie) takich, jak np. twórca, tytuł, temat. Te elementy (pola) mogą posiadać dowolną liczbę podpól, które z kolei mogą zawierać bardziej szczegółowe informacje, np. do zdigitalizowanej książki odnoszą się co najmniej dwie daty: data publikacji i data digitalizacji. Aby uzyskać w pełni uporządkowane informacje, obydwie daty powinny być zarejestrowane jako odpowiednie podelementy pola data. Tak określony układ kategorii ułatwia tworzenie opisów, czyni je bardziej przejrzystymi i czytelniejszymi zarówno dla ludzi jak i programów komputerowych. Aby uzyskać szczegółowe wyjaśnienie dlaczego usystematyzowany opis jest lepszy niż lista słów kluczowych, proszę wrócić do poprzedniej części tej lekcji gdzie opisywaliśmy dzieło Leonarda DaVinci. Schemat metadanych może ponadto określać to, jakie informacje mogą zostać wprowadzone w danym polu, które elementy są wymagane oraz które pola mogą zostać powtórzone. Bywa jednak, że schemat nie mówi w jaki sposób informacje powinny być sformułowane. Można to zrobić na dwa sposoby:
  • stosując terminy i wyrażenia zawarte w słowniku kontrolowanym,
  • lub precyzując zasady kodowania (zapisu), niezbędne dla niektórych informacji (np. daty, kolejność imienia i nazwiska).
Stosowanie słowników kontrolowanych i zasad kodowania jest bardzo ważne. W kolejnej części znajdzie się więcej informacji na temat korzyści z nich płynących. Należy jednak pamiętać, że w przypadku niektórych pól, takich jak np. Tytuł, nie ma sensu korzystanie ze słownika kontrolowanego. Schematy metadanych takie jak Dublin Core Metadata Elements Set (DCMES) wyraźnie określają, które pola wymagają użycia słownika.

Czym jest słownik kontrolowany?

Słownik kontrolowany, w ogólnym rozumieniu, jest listą terminów i wyrażeń, które mogą zostać użyte w celu tworzenia metadanych. Jedną z podstawowych zalet wszystkich rodzajów słowników kontrolowanych jest fakt, że dana jednostka lub temat zawsze stosowane są w ten sam sposób, np. hasło "II wojna światowa" zostanie użyte za każdym razem, gdy dany obiekt cyfrowy będzie odnosił się do tego tematu. To samo wyrażenie może być zapisane na wiele sposobów np. druga wojna światowa, 2. wojna światowa itd. Gdy stosuje się daną terminologię powinno się korzystać wyłącznie z pojęć zawartych w słowniku kontrolowanym. Jeśli stosowany słownik jest ogólnie znany, może znacznie poprawić wyniki wyszukiwania i umożliwić stworzenie bardziej zaawansowanych mechanizmów wyszukiwania. Istnieje kilka typów słowników kontrolowanych: listy terminów, tezaurusy, hasła przedmiotowe, kartoteki haseł wzorcowych i schematy klasyfikacyjne. Różnią się one nieco od siebie, ale każdy z nich jest pomocny przy tworzeniu metadanych. Listy terminów (ang. word list) są to proste predefiniowane listy pojęć, jednoznacznych i ściśle zdefiniowanych w zakresie całej listy. Lista terminów nie posiada hierarchii haseł (nie wskazuje powiązań między nimi), pomaga natomiast ustalić w jakiej formie dany wyraz może zostać użyty w rekordzie metadanych, a tym samym ograniczyć liczbę możliwych wartości dla danego pola, np. "gazeta" zamiast "gazety". Tezaurus (ang. thesaurus) porządkuje elementy (słowa i frazy) w sposób hierarchiczny, umożliwiający dostęp zarówno do pojęć ogólnych, jak i szczegółowych, np. dom (termin węższy) to rodzaj budynku (termin szerszy). Zwykle podaje również informację na temat terminów pokrewnych, synonimów (słów o tym samym znaczeniu) oraz haseł preferowanych (który z synonimów powinien być używany w pierwszej kolejności). W poradniku “Controlling your Language: a Directory of Metadata Vocabularies” [źródło] można znaleźć przykład dwóch haseł z tezaurusa: dwellings (budynki mieszkalne)
  • termin preferowany: houses (domy)
houses (domy)
  • pojęcie szersze (PS) = buildings (budynki)
  • pojęcie węższe(PW) = cottages (chaty)
  • pojęcie powiązane (PP) = palaces (pałace)
  • używaj zamiast: dwellings (budynki mieszkalne)
Tezaurus stanowi ogromną pomoc dla użytkowników nie posiadających dostatecznej wiedzy w danej dziedzinie, np. dla tych, którzy nie wiedzą dokładnie jakich terminów należy użyć. Wordnet [żródło] to jeden z najsłynniejszych tezaurusów na świecie, który oprócz relacji między hasłami podaje również ich definicje. Użytkownicy mogą przeglądać tezaurus, aby znaleźć właściwy termin, a następnie przejść do zapytania, które pozwoli dotrzeć do dokumentu dotyczącego danego zagadnienia bądź odpowiadającego na ich pytanie. Hasła przedmiotowe (ang. subject headings), podobnie jak w przypadku tezaurusa, w przypadku haseł przedmiotowych mamy również do czynienia z hierarchią pojęć, jednak funkcjonuje ona inaczej. Tezaurusy zezwalają na wybranie hasła lub wyrażenia, natomiast hasła przedmiotowe mogą być połączone w taki sposób, aby wyrażały bardziej szczegółowe pojęcie. Hasła przedmiotowe Biblioteki Kongresu (Library of Congress Subject Headings, LCSH) to najczęściej używany słownik haseł przedmiotowych, zawierający 270 000 takich haseł jak: "Art and the war” (Sztuka i wojna) czy “World War, 1939-1945” (Wojna światowa 1939-1945). Mogą one zostać użyte w metadanych danego obiektu. Jak wspomniano, hasła przedmiotowe mogą być łączone np. hasło "Wojna światowa, 1939-1945 - Sztuka i wojna" zawęża wyrażenie "Sztuka i wojna" do okresu II wojny światowej. Listy terminów, tezaurusy oraz hasła przedmiotowe powstały w celu zwiększenia wydajności wyszukiwania opartego na metadanych. Użytkownicy muszą być świadomi, że tego typu mechanizm został użyty w danej wyszukiwarce, aby właściwie z niego korzystać. Trudności, jakie mogą się z tym wiązać oraz właściwości słowników kontrolowanych zostaną omówione w dalszej części tego rozdziału. Klasyfikacja (ang. classification) to kolejny typ słownika kontrolowanego, utworzonego głównie w celu porządkowania zasobów. W tradycyjnej bibliotece zbiory są sklasyfikowane, aby łatwiej można było je odnaleźć na półkach z książkami. Każda pozycja została opisana przy pomocy wielu haseł przedmiotowych, ale przypisana tylko do jednego działu na półce. W erze digitalizacji różnica pomiędzy klasyfikacją, a hasłami przedmiotowymi staje się mniej wyraźna. "Klasyfikacje zwykle są hierarchiczne: rozpoczynają się szerokim zakresem przedmiotowym, a następnie dzielą się na coraz węższe tematy. Pod tym względem klasyfikacje przypominają tezaurusy, jednak ich struktura jest znacznie bardziej sztywna. O ile w przypadku tezaurusa może wystąpić więcej niż jeden węższy termin (mówimy wówczas o "polihierarchii"), o tyle schematy klasyfikacyjne ograniczają jednoznacznie jego zakres rzeczowy. Stąd klasyfikacje proponują jednostkowy punkt widzenia, narzucający strukturę, która nigdy nie będzie odpowiadała wszystkim użytkownikom. W przeciwieństwie do tezaurusów, schematy klasyfikacji wprowadzają ograniczenia poprzez stosowanie liczb i kodów. Na przykład w klasyfikacji dziesiętnej Deweya zasoby dotyczące buddyzmu zwykle przypisane są do liczby "294". Liczby te mają duże znaczenie: od 200 wzwyż dotyczą "Religii"; powyżej 290 "Innych religii" (należy zaznaczyć, że większość liczb pomiędzy 200 a 289 odnosi się do chrześcijaństwa); z kolei te oznaczone jako 294 dotyczą "Religii pochodzenia indyjskiego". Tak przejawia się XIX-wieczny światopogląd Zachodu, na którym opiera się klasyfikacja dziesiętna Deweya." [źródło] Ostatnim, ale z pewnością nie mniej istotnym typem słowników, który zostanie opisany w tej części są listy haseł wzorcowych (ang. authority lists) nazywane też kartotekami haseł wzorcowych. Zawierają one informacje o osobach, organizacjach i miejscach ustalone jako obowiązujące nazwy własne. Listy takie jak Hasła Wzorcowe Biblioteki Kongresu (Library of Congress Authorities, LCA) oferują obszerną (blisko 4-milionową) bazę nazw własnych, które z łatwością mogą zostać włączone do metadanych. Pozwala to ujednolicić nazwy własne, do których odnoszą się metadane. Dodatkowe informacje oraz przykłady można znaleźć w poradniku “Controlling your Language: a Directory of Metadata Vocabularies” (dostępny w języku angielskim), katalogu użytecznych słowników kontrolowanych, utrzymywanych przez JISC Digital Media Blog. W Polsce szeroko stosowane są dwie kartoteki haseł wzorcowych pierwsza stanowi część języka haseł przedmiotowych KABA (od Katalog Automatyczny Bibliotek Akademickich), jest utrzymywana przez Centrum NUKAT. Więcej informacji o na temat jej wykorzystania można znaleźć na stronach centrum NUKAT. Drugim ze stosowanych rozwiązań jest kartoteka utrzymywana przez Bibliotekę Narodową.

Czym jest interoperacyjność?

Wspomniano już pojęcie interoperacyjności, raz jeszcze zastanówmy się co ono oznacza? Jak podaje [źródło] interoperacyjność to "zdolność danych zasobów do współpracy z innymi, dzięki usługom pozwalającym na wyszukiwanie danych z wielu źródeł, czy też poprzez udostępnianie metadanych innym usługom". Jeżeli biblioteka cyfrowa funkcjonuje w środowisku internetowym, do jej zbiorów mają dostęp nie tylko użytkownicy, ale także inne witryny oraz biblioteki cyfrowe. W wielu przypadkach współpraca z innymi witrynami lub serwisami może okazać się korzystna, ale aby było to możliwe należy pamiętać o zgodności z ogólnie przyjętymi standardami metadanych. Standardy metadanych są rodzajem wspólnego języka, który pozwala na współpracę między dwoma witrynami lub zbiorami. Aby zapewnić wysoki poziom integracji pomiędzy dwoma zbiorami, obie usługi powinny korzystać z tych samych schematów metadanych (zapewnia to jednakową strukturę rekordu metadanych), tych samych słowników kontrolowanych i zasad kodowania np. dla dat. Lista może wydawać się kompletna, ale należy wiedzieć o jeszcze jednej rzeczy. 6 Ilustracja 6. Przykład rekordu Dublin Core zapisanego w XML [źródło]. Niezależnie od określonych zasad kodowania (np. dat) dotyczących niektórych pól, w większości standardów metadanych określono sposób zapisu całego rekordu. W przypadku katalogu kartkowego bibliotekarz dysponował kartką papieru z serią etykiet i pustych pól (formularzem), które musiał wypełnić; było tam miejsce na zawarcie takich informacji jak twórca czy sygnatura miejsca. Większość współczesnych schematów metadanych może być zapisana za pomocą języka XML (eXtensible Markup Language), który jest bardzo dobrze rozumiany przez programy komputerowe. Ilustracja nr 1 prezentuje przykład dokumentu zapisanego w XML. Osoba opracowująca zbiory na potrzeby biblioteki cyfrowej z reguły nie musi znać się na składni XML, język ten jest wykorzystywany jako podstawa dla działania oprogramowania. Niemniej jednak warto wiedzieć czym jest XML i być świadomym jego ogromnej roli w kontekście zapewniania interoperacyjności między różnymi źródłami danych.

Gdzie przechowywane są metadane?

Metadane mogą być osadzone wewnątrz obiektu cyfrowego (np. w pliku TIFF) lub przechowywane osobno (np. w bazie danych biblioteki cyfrowej). Czasem niemożliwe jest przechowywanie metadanych wewnątrz pliku z powodu ograniczeń, jakie narzuca jego format. Przechowywanie metadanych razem z opisywanymi danymi daje wiele korzyści (obiekt cyfrowy jest wówczas kompletny i nie wymaga żadnych innych źródeł), wiąże się z tym jednak także pewne ryzyko. Metadane zawarte w pliku łącznie z obrazem mogą zostać łatwo usunięte, nawet przez przypadek, bądź z braku odpowiednich funkcji oprogramowania używanego do przetwarzania końcowego, gdyż nie wszystkie edytory graficzne zapewniają obsługę metadanych. W przypadku gdy rekord metadanych zostanie zmieniony należy zmianę tę wprowadzić we wszystkich plikach, które ten rekord opisuje. Nie da się ukryć, że może to być bardzo uciążliwe. Metadane są przeważnie przechowywane w odpowiednio do tego przystosowanej bazie danych mogą być składowane w odrębnym pliku tekstowym lub XML, przechowywanym obok obiektu cyfrowego. Wszystkie narzędzia do budowy bibliotek cyfrowych oferują tego typu rejestr metadanych. Metadane dotyczące jednego obiektu są przechowywane w jednym miejscu w związku z tym wprowadzając zmianę nie musimy jej nigdzie kopiować. Niektóre narzędzia do tworzenia bibliotek cyfrowych oferują również funkcje, które pozwalają na utrzymywane spójności tworzonych rekordów.

Klasyfikacja standardów metadanych

Ta część kompendium ma na celu zebranie w jednym miejscu kilku wskazówek, które mogą pomóc odnaleźć się w ogromnej liczbie standardów metadanych. Jak już wiadomo, metadane mogą służyć różnym celom, co może stanowić pierwsze kryterium do klasyfikacji. Innym kryterium klasyfikacji może być to jakie instytucje korzystają z danego standardu, ze względu na sposób funkcjonowania i potrzeby muzea, archiwa i biblioteki stosują inne standardy zapisu metadanych. Trzeci podział związany jest z rolą metadanych na różnych etapach digitalizacji. Standardy metadanych mogą być sklasyfikowane ze względu na funkcje, które pełnią [źródło]:
  • metadane opisowe
    • stosowane przy wyszukiwaniu i interpretacji obiektu cyfrowego
    • przykłady:
      • Dublin Core Metadata Element Set, DCMES
      • Metadata Object Description Schema, MODS
      • Categories for the Description of Works of Arts, CDWA
      • Visual Resources Association Core, VRE
      • SEPIA Data Element Set, SEPIADES
      • Public Broadcasting Metadata Dictionary, PB Core
      • MPEG-7
  • metadane strukturalne
    • opisują logiczny i fizyczny związek pomiędzy częściami złożonego obiektu
    • przykładem może być:
      • Metadata Encoding and Transmission Schema, METS
  • metadane administracyjne
    • służą do zarządzania obiektem cyfrowym, zapewniają dostęp do informacji na temat jego powstania oraz wszelkich ograniczeń dotyczących jego wykorzystania
    • czasem wyróżnia się:
      • metadane konserwatorskie
        • przeznaczone do zapewniania długoterminowego przechowywania
        • przykłady:
          • słownik danych PREMIS
      • metadane źródłowe
        • opisujące obiekt, z którego powstał zasób cyfrowy, na poziomie opisu zbioru
      • metadane proweniencyjne
        • opisujące historię operacji przeprowadzonych na danym obiekcie cyfrowym od momentu jego powstania
      • metadane prawne
        • opisujące prawa autorskie, ograniczenia dotyczące użycia oraz umowy licencyjne ograniczające wykorzystanie zasobu
Istnieje również inna kategoria, którą można tutaj wyróżnić, chodzi o metadane wykorzystywane do opisu kolekcji. Kolekcje są elementami składowymi, wokół których mogą być tworzone usługi cyfrowe. Powinny być opisane w taki sposób, aby użytkownik mógł wyszukać ważne dla kolekcji cechy takie jak charakter materiałów zawartych w danej kolekcji, format, prawo własności oraz ograniczenia w dostępie. Opis pozwala również na zintegrowanie istniejących kolekcji pochodzących z różnych bibliotek cyfrowych w nowych usługach. Ta część kompendium będzie poświęcona głównie metadanym opisowym, ale pojawią się również informacje na temat metadanych opisujących kwestie związane z prawami autorskimi. Metadane strukturalne, a niekiedy także techniczne mogą być tworzone automatycznie przez oprogramowania do tworzenia bibliotek cyfrowych lub programów do archiwizacji materiałów cyfrowych, dlatego w tym miejscu zostaną pominięte. W pierwszym rozdziale przedstawiono podstawy organizacji procesu digitalizacji, na który składają się:
  • wybór obiektu przeznaczonego do digitalizacji,
  • przygotowanie metadanych obiektu,
  • wybór odpowiedniego sprzętu do digitalizacji,
  • skanowanie danego obiektu,
  • korekta uzyskanego obrazu za pomocą oprogramowania graficznego,
  • przygotowanie wersji do prezentacji w sieci,
  • zabezpieczenie cyfrowej kopii głównej (egzemplarza wzorcowego),
  • publikacja obiektu w bibliotece cyfrowej.
W wyniku prac, poza oryginalnym obiektem, zostaną uzyskane trzy dodatkowe elementy, z których każdy wymaga odrębnych metadanych:
  • obiekty cyfrowe powstałe w wyniku procesu digitalizacji (cyfrowa kopia główna/egzemplarz wzorcowy),
  • wszystkie obiekty pochodne od oryginalnego rezultatu digitalizacji (np. wersja do prezentacji w sieci),
  • zbiory wszystkich powyższych (opis na poziomie kolekcji).
Bogatsze schematy metadanych są używane do opisu cyfrowych kopii głównych, wersje do prezentacji w sieci zwykle opisywane są za pomocą tego samego opisu bądź jego uproszczonej formy zredagowanej przy pomocy np. Dublin Core Metadata Element Set (DCMES). W niektórych przypadkach tworzenie własnych metadanych opisowych nie jest konieczne, mogą one już dla danej pozycji istnieć w systemie katalogowym (np. OPAC). Należy wówczas zaimportować taki opis do biblioteki cyfrowej. Opis ten z pewnością odnosi się do obiektu fizycznego, dlatego może wymagać korekty, np. poprzez dodanie informacji natury technicznej i strukturalnej dotyczącej plików czy procesu digitalizacji. Niektóre standardy umożliwiają opis w jednym rekordzie metadanych obydwu obiektów, zarówno fizycznego jak i cyfrowego (m.in. Categories for the Description of Works of Arts, CDWA). Jednak w przypadku Dublin Core Metadata Element Set, DCMES jeden rekord powinien odnosić się tylko do jednego obiektu.

Dublin Core to nie wszystko

Jak już wspomniano, ta część kompendium obejmuje głównie metadane opisowe, ale pojawi się wyjątek w postaci opisu standardu METS. W następnej części będzie można dowiedzieć się więcej o Dublin Core Metadata Element Set, a w materiałach dodatkowych zaprezentowano kilka standardów, które mogą okazać się przydatne. Celem prezentowanych w tym kompendium opisów jest wyposażenie użytkownika w podstawową wiedzę na temat najistotniejszych standardów metadanych, z punktu widzenia bibliotek, muzeów i archiwów. Najważniejsze to wiedzieć gdzie szukać, więc jeśli nie znajdzie się odpowiedniego dla siebie schematu w ramach niniejszego kursu, będzie można go znaleźć samodzielnie.
Należy wspomnieć, że wybór schematu dokonuje się przeważnie na poziomie całej biblioteki cyfrowej. Do sytuacji takiej dochodzi więc w miarę rzadko, w przypadku gdy instytucja dołącza do istniejącego konsorcjum bibliotek współpracujących przy już istniejącej bibliotece cyfrowej standardy metadanych są już przeważnie dobrze określone.

Opis standardów Dublin Core

Zestaw Elementów Metadanych Dublin Core (Dublin Core Metadata Element Set, DCMES) [źródło] powstał w wyniku debaty, która miała miejsce w 1995 roku w Dublinie, w amerykańskim stanie Ohio. Początkowa dyskusja oraz jej dalszy rozwój doprowadziły do powstania specyfikacji Dublin Core Metadata Element Set. DCMES jest obecnie rozwijany przez Dublin Core Metadata Initiative (DCMI), organizację, która angażuje się również w inne działania mające na celu ustanowienie najlepszych praktyk w zakresie metadanych. "Pierwotnym założeniem Dublin Core było zdefiniowanie zbioru elementów, które mogłyby być użyte przez autorów do opisu ich własnych zasobów sieciowych. Wobec rozrastania się zasobów elektronicznych i niemożności skatalogowania ich wszystkich przez biblioteki, celem stało się określenie kilku elementów i prostych zasad, które mogłyby stosować osoby nie zajmujące się zawodowo katalogowaniem." [źródło]. DCMES został opracowany w sposób prosty i zwięzły, początkowo był przeznaczony dla dokumentów sieciowych. Pierwotnie specyfikacja zawierała 13 elementów, później rozszerzono ją do 15 i w tej formie istnieje do dziś. Elementy te to:
  • Tytuł (Title),
  • Twórca (Creator),
  • Temat (Subject),
  • Opis (Description),
  • Wydawca (Publisher),
  • Współtwórca (Contributor),
  • Data (Date),
  • Typ (Type),
  • Format (Format),
  • Identyfikator (Identifier),
  • Źródło (Source),
  • Język (Language),
  • Powiązanie (Relation),
  • Zakres (Coverage),
  • Prawa (Rights).
Z czasem katalogujący zaczęli stosować DCMES również w odniesieniu do innych materiałów. Od 2003 roku DCMES jest standardem ISO, co dowodzi, że jest to powszechnie znane i ważne rozwiązanie w tej dziedzinie. Dublin Core jest szeroko uznanym wyznacznikiem metadanych, i może dlatego jest stosowany jako podstawa dla OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting), protokołu, który umożliwia bibliotekom cyfrowym współpracę poprzez korzystanie z usługi przeszukiwania wspólnych zasobów. Przykładowy rekord metadanych Dublin Core: Twórca: Rose Bush Tytuł: A Guide to Growing Roses Opis: Describes process for planting and nurturing different kinds of rose bushes (opis procesu hodowli i pielęgnacji różnych gatunków krzewów różanych) Data: 2001-01-20 Specyfikacja DCMES precyzuje dokładną interpretację tych pól oraz wskazuje jakie informacje powinny one zawierać.
  • Twórca - zawiera informacje dotyczące jednostki bezpośrednio odpowiedzialnej za stworzenie zasobu.
  • Tytuł - nazwa nadana zasobowi.
  • Opis - wykaz zawartości danego zasobu.
  • Data - data lub odcinek czasu związany z danym zdarzeniem w okresie istnienia zasobu.
Wszystkie elementy DCMES są opcjonalne, wszystkie mogą również zostać powtórzone (można np. zdefiniować dwóch twórców). Jak widać DCMES jest bardzo prostym formatem metadanych, którego stosowanie rozprzestrzeniło się znacznie poza zasoby w sieci. W miarę jego upowszechnienia się część specjalistów zaczęła wymagać bardziej usystematyzowanego podejścia. W związku z tym DCMI opracowało standard Dublin Core Metadata Terms, DC Terms inaczej zwany Qualified Dublin Core (Kwalifikowanym Dublin Core), będącym rozszerzeniem standardu DCMES. DC Terms określa zbiór kwalifikatorów (podelementów), który pozwala doprecyzować informacje zawarte w rekordzie metadanych DCMES.
DC Terms zawiera następujące pola (w tym również pierwotne elementy DCMES; w nawiasach podano angielskie brzmienia nazw pól, kolejność alfabetyczna):
  • abstrakt (abstract),
  • prawa dostępu (accessRights),
  • metoda uzupełnienia zbioru (accrualMethod),
  • częstotliwość uzupełnienia zbioru (accrualPeriodicity),
  • reguły uzupełnienia zbioru (accrualPolicy),
  • wariant tytułu (alternative),
  • odbiorcy (audience),
  • dostępność (available),
  • cytata bibliograficzna (bibliographicCitation),
  • zgodny z (conformsTo),
  • współtwórca (contributor),
  • zakres (coverage),
  • data utworzenia (created),
  • twórca (creator),
  • data (date),
  • data przyjęcia (dateAccepted),
  • data copyright (dateCopyrighted),
  • data złożenia (dateSubmitted),
  • opis (description),
  • poziom edukacyjny odbiorcy (educationLevel),
  • rozmiary (extent),
  • format (format),
  • ma format (hasFormat),
  • ma część (hasPart),
  • ma wersję (hasVersion),
  • identyfikator (identifier),
  • metoda szkolenia (instructionalMethod),
  • jest w formacie (isFormatOf),
  • jest częścią (isPartOf),
  • ma odniesienie w (isReferencedBy),
  • zastąpiony przez (isReplacedBy),
  • jest wymagany przez (isRequiredBy),
  • data wydania (issued),
  • jest wersją (isVersionOf),
  • język (language),
  • licencja (license),
  • pośrednik (mediator),
  • nośnik (medium),
  • data modyfikacji (modified),
  • proweniencja (provenance),
  • wydawca (publisher),
  • odniesienia (references),
  • powiązanie (relation),
  • zastępuje (replaces),
  • wymaga (requires),
  • prawa (Rights),
  • właściciel praw (rightsHolder),
  • źródło (source),
  • zakres przestrzenny (spatial),
  • temat (subject),
  • spis treści (tableOfContents),
  • zakres czasowy (temporal),
  • tytuł (title),
  • typ (type),
  • data ważności (valid).
Dodatkowe elementy są tzw. uszczegółowieniem: "Uszczegółowienia elementów zawężają i precyzują znaczenie elementu. Uszczegółowiony element dziedziczy znaczenie niekwalifikowanego elementu (elementu nadrzędnego), ale ma bardziej ograniczony zakres. Zasada kwalifikacji elementów Dublin Core, potocznie znana jako zasada Dumb-Down, [źródło] głosi, że aplikacja, która nie rozpoznaje uszczegółowionego elementu, powinna móc zignorować kwalifikator i traktować wartości metadanych jako niekwalifikowany (szerszy) element. Choć może to prowadzić do pewnej utraty dokładności, zawartość takich elementów (bez kwalifikatora) powinna ogólnie pozostać poprawna i być wciąż użyteczna dla celów wyszukiwania". [źródło] Ilustracją tej zasady jest przywoływany już przykład pola Data, które może odnosić się do daty utworzenia, daty ostatniej modyfikacji czy nawet okresu ważności. Dla poprawnej interpretacji konieczne jest wprowadzenie podpól, których definicja wprost określi czego dotyczy dana data. W następnych częściach powrócimy do tematu Dublin Core, aby przedstawić bardziej szczegółowy obraz jego elementów oraz przykłady użycia.

Jak przygotować metadane opisowe?

Wprowadzenie

Poprzedni rozdział przybliżył podstawowe informacje na temat metadanych, ten wprowadza w proces ich tworzenia. W części pierwszej proces ten zostanie przedstawiony przekrojowo, począwszy od osób mogących w nim uczestniczyć, aż po informacje co należy zrobić, żeby przygotować metadane dla powstającej kolekcji cyfrowej. W kolejnych częściach będzie można znaleźć bardziej szczegółowy opis wymienionych etapów.

Jak wygląda tworzenie metadanych?

W pierwszej kolejności przyjrzyjmy się co należy zrobić. Poniższa lista przedstawia wykaz czynności niezbędnych do utworzenia metadanych dla nowo powstającej biblioteki cyfrowej. Lista kontrolna tworzenia metadanych i organizacja pracy
  1. Określenie wymagań
    1. Jaki jest cel kolekcji? Kto będzie z niej korzystał? Jak duża ma być? Ile jest czasu na przygotowanie metadanych?
  2. Rozpoznanie najlepszych praktyk w danej dziedzinie
    1. Przegląd podobnych bibliotek/kolekcji cyfrowych stworzonych przez inne instytucje. Odpowiedź na pytania: dlaczego zostały one utworzone w taki sposób? Dlaczego przy użyciu akurat takiego standardu?
  3. Wybór lub stworzenie schematu metadanych oraz dodatkowych zasobów (np. słowniki kontrolowane, dokumentacja wykorzystania standardu)
    1. Zapoznanie się wymaganiami, rozważenie rozwiązań przyjętych przez innych, rozpatrzenie potencjalnych standardów metadanych i dodatkowych narzędzi, takich jak słowniki kontrolowane czy hasła przedmiotowe.
    2. Można również rozważyć stworzenie własnej struktury opisu lub rozszerzenie istniejącego standardu metadanych, co zostanie szczegółowo opisane w dalszych częściach kursu.
  4. Nauka korzystania z wybranych narzędzi metadanych
    1. Osoby stosujące te narzędzia mogą nauczyć się korzystać z nich w trakcie pracy. Jeśli jednak jest taka możliwość, należy skonfrontować swoją wiedzę z wiedzą innych profesjonalistów, którzy posiadają praktyczne doświadczenie w pracy z danym schematem.
    2. Jeśli ktoś inny podejmuje pracę z danym schematem, powinno się mu objaśnić sposób jego wykorzystania, można wspólnie opracować wewnętrzne wymogi tworzenia metadanych.
  5. Tworzenie lub import metadanych
    1. Tworzenie metadanych
      1. Należy zdecydować ile czasu można poświęcić na opis jednego zasobu.
      2. Niezbędne jest rozpoznanie obiektu, który stanie się przedmiotem pracy, zidentyfikowanie źródła informacji, zdobycie potrzebnej wiedzy.
      3. Przygotowanie opisu danego obiektu.
      4. Umieszczenie opisu w rejestrze metadanych, pliku lub bibliotece cyfrowej.
    2. Import metadanych
      1. Jeśli opis danego obiektu został już przez kogoś przygotowany, można spróbować oprzeć się na jego pracy. Można importować metadane z istniejącego katalogu biblioteki lub też innego źródła.
      2. Należy pamiętać, aby sprawdzić czy importowany opis jest zgodny z naszymi założeniami i wybranym schematem metadanych.
  6. Ocena jakości metadanych
    1. Jeśli importowany opis był powiązany z obiektem fizycznym, należy go ponownie sprawdzić, aby uniknąć pomyłek.
    2. Należy określić kryteria poprawności, jeśli to możliwe sprawdzić metadane przy pomocy zewnętrznego walidatora.
  7. Dostosowanie metadanych do bieżących potrzeb
    1. Gdy stanie się jasne, kto będzie użytkownikiem danej kolekcji, właściwe może okazać się dostosowanie metadanych, w celu lepszego wykorzystania zasobu przez przyszłych użytkowników.
    2. Dostosowanie metadanych może również być niezbędne w celu udostępnienia zasobów innym inicjatywom np. portalowi Europeana.
Kolejne części tej lekcji zawierają więcej informacji na temat wymienionych etapów. Początkowe etapy są istotne tylko w przypadku tworzenia nowej kolekcji cyfrowej. Po ustaleniu wstępnych założeń będzie można się skoncentrować głównie na tworzeniu metadanych, co stanowi sedno punktów 5, 6 i 7.

Kto tworzy metadane?

Jak już wspomniano w poprzednim rozdziale, istnieje wiele kategorii metadanych, w tym metadane opisowe, administracyjne i strukturalne. Wszystkie są istotne dla dostępu do informacji zawartych w opisywanym obiekcie. Opisany wcześniej przebieg prac nad tworzeniem metadanych obejmuje tworzenie różnych rodzajów metadanych, należy zatem postawić pytanie: kto może uczestniczyć w tym procesie? Zależy to od stopnia skomplikowania danego schematu. Jeśli schemat jest prosty (tak jak np. Dublin Core Metadata Element Set) każdy może po krótkim szkoleniu tworzyć poprawne opisy. Jakie umiejętności mogą być przydatne przy tworzeniu metadanych? Oprócz wiedzy na temat katalogowania, dobrze jest posiadać pewną wiedzę specjalistyczną z danej dziedziny. W bibliotekach naukowych powszechną praktyką jest angażowanie autora lub eksperta w danej dziedzinie, w celu pozyskania wiedzy na temat konkretnego zasobu lub publikacji. Tego typu zewnętrzna pomoc pozostaje jednak tylko źródłem wiedzy z danego zakresu, natomiast katalogujący jest odpowiedzialny za tworzenie opisu/metadanych. Jeżeli katalogujący nie ma możliwości skorzystania z pomocy eksperta, może sam poszukiwać informacji na temat zasobu, jest to jednak czasochłonne. Jeśli nie dysponuje się czasem, należy skoncentrować się na rzeczach, które można wykonać, gdyż nawet ogólnikowy opis jest bardziej przydatny niż jego brak. Jeżeli system biblioteki cyfrowej zezwala na dodawanie komentarzy bądź tagów, katalogujący może wprowadzić tyle metadanych, ile to możliwe i pozwolić użytkownikom na poszerzanie opisu. Doskonałym przykładem takiego postępowania jest wspomniany już projekt “Flickr.com: The Commons”, który zezwala na adnotacje dotyczące archiwalnych fotografii w celu uzyskania dodatkowych metadanych na temat obiektu.

Czy słowniki kontrolowane naprawdę są tak ważne?

"Zwykle istnieje bezpośredni związek pomiędzy kosztem tworzenia metadanych, a spełnieniem potrzeb użytkowników: opisywanie każdej pozycji jest bardziej kosztowne niż opisywanie kolekcji czy grup obiektów; użycie obszernych, złożonych schematów metadanych jest bardziej kosztowne niż korzystanie z prostego schematu; stosowanie standardowych słowników haseł przedmiotowych i klasyfikacji jest bardziej kosztowne niż przypisanie kilku niekontrolowanych słów kluczowych itd. Należy jednak zauważyć, że inwestycja w rozwój często skutkuje większą wydajnością i efektywnością dla końcowego użytkownika. Użycie standaryzowanego tezaurusa lub innego słownika kontrolowanego może na przykład zapewnić większą dokładność i ponowne przywołanie zrealizowanego wcześniej rezultatu wyszukiwania, może również zapewnić funkcjonalność na przyszłość [...]" [źródło]. Lista funkcji zaawansowanych obejmuje różnego rodzaju usprawnienia związane z przeszukiwaniem, tworzeniem list wyników i przeglądaniem tychże list. Należy tu wspomnieć o wykorzystaniu technologii wyszukiwania semantycznego (inteligentnego) oraz automatycznym tłumaczenie metadanych na inne języki. Są to funkcje, które z pewnością zostaną docenione przez użytkowników w sytuacji gdy będą oni musieli przeglądać duże zbiory dokumentów. Dzięki użyciu słowników kontrolowanych możliwe jest zapewnienie wspólnego zrozumienia terminów stosowanych w metadanych. Niektóre ze słowników kontrolowanych mają wersje w kilku językach, więc dzięki ich zastosowaniu możliwe jest automatyczne tłumaczenie opisu na inny język występujący w danym słowniku kontrolowanym. Przeanalizujmy następujący przykład (pochodzący z “Metadata and digital images”, poradnika dostępnego na stronie JISC Media blog). Wyobraźmy sobie cyfrowy obraz motyla siedzącego na fioletowym kwiecie. Dla laika jest to po prostu ładny motyl, kto inny rozpozna w nim "monarchę", który posiada także łacińską nazwę (nazwa ta może być używana przez specjalistów) Danaus plexippus. Oprócz oczywistych nazw, użytkownicy mogą zapytać również o owada o dużych pomarańczowych skrzydłach. Różni użytkownicy mają różne sposoby postrzegania rzeczy i w różny sposób formułują swoje potrzeby informacyjne. Przykład ten pokazuje, że właściwy słownik może być rzeczywiście bardzo ważny, w zależności od tego kto korzysta ze zbioru. Prawdą jest, że większość internautów nie zna łacińskich nazw gatunków, ale nazwy zwyczajowe mogą być łatwo włączone do słownika jako pojęcia zamienne i automatycznie dodane do rekordu metadanych. Uwaga: Słownik kontrolowany użyty dla danego elementu pozwala łatwo wykorzystać informacje zawarte w metadanych do celów statystycznych np. określić liczbę wszystkich gazet w zbiorach biblioteki cyfrowej. W sytuacji gdy dla określenia gazet stosowanych jest kilka różnych terminów taka analiza jest dużo trudniejsza. Czy wszystkie elementy wymagają powiązania ze słownikiem kontrolowanym? W większości przypadków nie jest to konieczne, słownik zwykle jest używany dla zawarcia następujących informacji:
  • temat zasobu cyfrowego np. II wojna światowa
  • typ zasobu np. gazeta
  • język zasobu np. niemiecki
  • nazwy twórców, miast, miejsc, zdarzeń
  • prawa wykorzystania zawartości np. Creative Commons BY-NC-SA

Standardy zapisu wartości opisu

Wspomniano już o tym jak ważne jest stosowanie spójnych standardów w zakresie zapisu wartości tzw. schematów kodowania wartości. Dlaczego jest to takie ważne? Proszę wyobrazić sobie sytuacje w której chcemy przeszukać gazety pochodzące z lat 1931-1939. W sytuacji gdy w polu opisu dedykowanym dacie publikacji zapisano tylko rok za pomocą cyfr arabskich, wyszukiwarka nie powinna mieć problemu z odnalezieniem właściwych obiektów. Gdy jednak katalogujący użyje notacji za pomocą cyfr rzymskich sytuacja się nieco komplikuje. Do tego dochodzi kwestia zapisu daty dziennej itp. Aby móc stworzyć wydajne narzędzia umożliwiające wyszukiwanie, konieczne jest przestrzeganie pewnych zasad zapisu.
Przykładami standardów regulujących kwestie zapisu różnego rodzaju informacji są (rekomendacje pochodzą z dokumentów opublikowanych na stronach DCMI):
  • ISO 3166-1, ISO 3166-2 and ISO 3166-3, określa jak zapisywać kody nazw państw i języków
  • DCMI Period – wykaz przedziałów czasowych określonych zakresami wg Schematu Kodowania Czasu DCMI (DCMI Period Encoding Schema)
  • DCMI Point - wykaz miejsc oznaczonych współrzędnymi geograficznymi wg Schematu Kodowania Miejsc DCMI (DCMI Point Encoding Scheme)
  • RFC1766, RFC3066 and RFC4646 – zestawy znaczników służących do identyfikacji języków
  • URI – zestaw ujednoliconych identyfikatorów zasobów, tworzonych zgodnie ze standardową gramatyką Uniform Resource Identifiers
  • W3CDTF – specyfikacja dat i czasów (Date and Time Format Specifiation).

Co to jest folksonomia?

Wybór informacji które zostaną zawarte w rekordzie metadanych zależy głównie od tego, dla kogo dana kolekcja jest tworzona. Jeśli jest przeznaczona dla naukowców, twórca powinien używać języka dziedzinowego. Skoro jednak większość kolekcji trafia wcześniej czy później do Internetu, przygotowanie metadanych w taki sposób, aby były one przystępne dla wszystkich zainteresowanych jest niewątpliwie zadaniem bardzo trudnym. Jak poradzić sobie z tym problemem? W tej części zostanie wyjaśniony termin folksonomia, zaproponowany przez Thomasa Vander Wala, a powstały z połączenia dwóch słów: ludzie (ang. folks) i taksonomia. Folksonomia jest znana również jako wspólne tagowanie lub indeksowanie społeczne. Indeksowanie społeczne pozwala użytkownikom na ujęcie w słowa tego, jak postrzegają oni dany zasób. Wracając do przykładu motyla monarchy, użytkownik, który trafi na ten zasób, mógłby uznać metadane za niekompletne, ponieważ opis nie wspomina nic o kwiecie widocznym na fotografii. Może on wówczas dodać tag "fioletowy kwiat", dzięki czemu inny użytkownik zainteresowany obrazem kwiatu, będzie mógł odnaleźć ten obraz. Niektóre systemy bibliotek cyfrowych zapewniają funkcję tagowania społecznościowego, etykiety (tagi) dodane przez użytkowników są wówczas prezentowane razem z metadanymi, a w niektórych przypadkach mogą zostać włączone do opisu obiektu.

Gdzie i jak przechowywać metadane?

W poprzedniej części wspomniano, że metadane mogą być przechowywane:
  • w oddzielnym pliku tekstowym,
  • wewnątrz obiektu cyfrowego,
  • w przeznaczonej do tego celu bazie danych.
Używając jednego z najbardziej znanych narzędzi do tworzenia bibliotek cyfrowych, nie trzeba się specjalnie martwić o wybór mechanizmu gromadzącego metadane. Takie narzędzie pozwalają tworzyć metadane poprzez wpisanie wartości w formularzu i zapisanie ich. Oprogramowanie biblioteki cyfrowej będzie w tle indeksować dodane metadane, wyświetlać je użytkownikom i zapewni inne zaawansowane usługi (takie jak słownik kontrolowany, konwersja metadanych itd.) bez konieczności nabycia zaawansowanej wiedzy na temat języka XML, czy bycia specjalistą od kodowania plików tekstowych. Ilustracja 7 przedstawia edytor schematu metadanych, będący częścią oprogramowania dLibra, systemu stosowanego dla bibliotek cyfrowych. Pozwala on tworzyć bardzo wyszukane schematy metadanych, a także łatwo mapować do atrybutów Dublin Core schemat dostosowany dla własnych zbiorów. Dzięki temu można dość łatwo uwidocznić dane dla zewnętrznych usług/stron internetowych na przykład poprzez OAI-PMH.
7 Ilustracja 7. Pokazuje w jaki sposób działa edytor schematu metadanych w systemie dLibra. 8 Ilustracja 8. Przedstawia proces tworzenia metadanych w bibliotece cyfrowej powstałej przy użyciu oprogramowania dLibra Niektóre systemy do budowy bibliotek cyfrowych pozwalają importować metadane z zewnętrznych źródeł. Ilustracja 8 pokazuje inne protokoły i standardy, które pozwalają importować istniejące metadane do biblioteki cyfrowej. 9 Ilustracja 9. Okno z możliwościami wyboru źródła, które może być użyte w celu importowania metadanych do biblioteki cyfrowej.

Jak można opisywać kolekcje?

Wokół kolekcji mogą powstać usługi cyfrowe różnego typu. Powinny być one opisane w taki sposób, aby użytkownik mógł rozpoznać najważniejsze cechy kolekcji, w tym jej zakres, format, prawa własności i ograniczenia dostępu. Opis pozwala również na zintegrowanie kolekcji z usługami cyfrowymi odnoszącymi się do tychże kolekcji. Mogą one być opisane w sposób nieformalny (patrz tutaj) lub przy użyciu metadanych o określonej strukturze. Podstawową korzyścią formalnych metadanych jest możliwość ich łatwego ponownego wykorzystania i wymiany. Istnieje tylko kilka rozwiązań dostosowanych do opisywania kolekcji, m.in. Dublin Core Collection Description Application Profile [źródło]. Warto pamiętać, że jeśli opis obiektu jest ponownie wykorzystany, razem z nim powinien być rozpowszechniany też opis kolekcji.

Jak ocenić jakość metadanych?

W poprzednich częściach tego rozdziału przedstawiono większość cech, jakimi powinny się charakteryzować poprawne metadane. Ta część przedstawia kilka podstawowych sposobów ewaluacji jakości metadanych. Ocena ta powinna wziąć pod uwagę poprawność wszystkich warstw rekordu metadanych:
  • jego zgodność z wybranym standardem,
  • dokładność i poprawność opisu w zakresie danej dziedziny wiedzy,
  • to, czy rekord metadanych służy celom, jakie się przed nim stawia.
Zgodność ze standardem wiąże się głównie ze strukturą (składnią) rekordu metadanych oraz zasadami kodowania rekomendowanymi w standardzie. Jeśli dany standard używa składni opartej na XML, jego poprawność może być sprawdzona automatycznie przy pomocy przeznaczonych do tego programów komputerowych, zwanych walidatorami. Taki program może automatycznie sprawdzić:
  • poprawność składni XML,
  • to, czy dane dane pole zawiera datę w formacie wymaganym przez standard,
  • to, czy wartości w danym polu zawierają słowa wyłącznie z określonego słownika kontrolowanego.
Bazując na wynikach takiego programu komputerowego można poprawiać błędy i uzgadniać metadane z danym schematem. Walidacja merytoryczna opisu jest zadaniem raczej dla ludzi i nie istnieją na razie programy komputerowe pozwalające na automatyczne sprawdzenie tego aspektu. Dotyczy to takich kwestii, jak np. czy obraz cyfrowy odzwierciedla rysunek lub fotografię. Taka weryfikacja wymaga pewnej znajomości danej dziedziny oraz wiedzy na temat opisywanego zasobu, która nadal jest niedostępna dla programów komputerowych. Poza dostępem do wiedzy, metadane prezentują subiektywny punkt widzenie katalogującego, mogący różnić się diametralnie od poglądu oceniającego. Czasem trudno ocenić użyteczność czy też poprawność metadanych, dlatego istnieje kilka skutecznych sposobów oszacowania czy dany rekord jest przydatny z punktu widzenia podstawowych potrzeb użytkowników. Jedna z metod została przygotowana w trakcie realizacji projektu Minerva i nosiła nazwę DC Culture. DC Culture jest szerszą koncepcją, ale dla potrzeb tego kursu należy przede wszystkim podkreślić, że rekord metadanych powinien zawierać tyle informacji, aby odpowiadał na cztery podstawowe pytania: kto? co? gdzie? kiedy? Powinny one stać się punktem wyjścia dla wszelkich metadanych opisowych. Spróbujmy ocenić czy poniższy rekord zawiera odpowiedzi na wspomniane pytania oraz który z elementów opisu na nie odpowiada:
Twórca: Rose Bush Wydawca: Ronald Wydawca Tytuł: A Guide to Growing Roses Opis: Opisuje proces sadzenia i pielęgnacji różnych gatunków krzewu róży. Data: 2001-01-20Odpowiedzi będą następujące:
  • Kto?
    • Twórca: Rose Bush
    • Wydawca: Ronald Wydawca
  • Co?
    • Tytuł: A Guide to Growing Roses
    • Opis: Opisuje proces sadzenia i pielęgnacji różnych gatunków krzewu róży.
  • Kiedy?
    • Data: 2001-01-20
  • Gdzie?
    • -
Rekord metadanych zawiera informacje na temat tego, kto był autorem, jaki jest tytuł zasobu, czego dotyczy i kiedy został opublikowany. Nie ma odpowiedzi na pytanie "gdzie?", co może wskazywać, że pewne informacje powinny zostać uzupełnione. Jak widać, odpowiedzi mogą mieć różny poziom abstrakcji i odnosić się do różnych aspektów obiektu cyfrowego. Oceniając jakość rekordu metadanych należy pamiętać, że informacje w nim przechowywane powinny być wystarczalne dla jego poprawnej interpretacji. Co to znaczy? Trzeba pamiętać, że metadane mogą zostać ponownie wykorzystane (oczywiście jeśli wyrazi się na to zgodę) na innych witrynach lub portalach internetowych i w takim przypadku będą prezentowane w innym kontekście. "Poprawne metadane powinny być spójne, bogate w treść i użyteczne w kontekście globalnym, również poza kontekstem w którym powstały. Oznacza to, że muszą zawierać wszystkie istotne informacje o obiekcie, gdyż założenia dotyczące kontekstu w którym są dostępne lokalnie, mogą okazać się nieuzasadnione w innym środowisku. Na przykład w archiwum fotograficznym nie każdy rekord musi wskazywać, że opisywany obiekt jest fotografią. Jednakże w szerszym kontekście forma i rodzaj informacji stają się ważne. Kolekcje cyfrowe ukierunkowane tematycznie cieszą się złą sławą, gdyż doprowadzają do tworzenia nieinteroperacyjnych metadanych, zakładając, że użytkownicy znają główny temat kolekcji. Gdy te metadane zostają udostępnione w ramach większej kolekcji, opisy mające sens w oryginalnym kontekście mogą wprowadzać w błąd. Przykładem może być opis kolekcji Teddy'ego Roosvelta, w Harvardzie, gdzie tytuł "na koniu", przypisany fotografii nie wskazywał kim jest postać siedząca na koniu, ponieważ cała kolekcja była poświęcona Roosveltowi." [źródło] Trzeba również mieć na uwadze wiele innych aspektów, z których część zostanie opisana w kolejnej części.

Czy opracowanie wewnętrznych wytycznych dotyczących metadanych jest konieczne?

Czy opracowanie wewnętrznych wytycznych jest naprawdę konieczne, jeśli pracuje się w małej bibliotece publicznej i jeśli jest się jedyną osobą odpowiedzialną za digitalizację? Powinno się opracować własne wytyczne z następujących powodów:
  • pozwoli to jasno określić dlaczego korzystamy z danego standardu,
    • Jeśli został stworzony własna specjalizacja standardu (tzw. profil aplikacyjny), należy wyjaśnić i udokumentować metodę postępowania, która do tego doprowadziła.
      • Które pola są obowiązkowe (jeśli występują),
      • Które elementy zostały dodane do schematu i w jakim celu
    • Jaki zakres terminologiczny został wybrany do opisu każdego elementu
    • Jakie zastosowano zasady kodowania dat, okresów czasu, nazw własnych, miejsc itd.
    • Kryteria, według których dokonano oceny jakości opracowanych metadanych
  • Dzięki temu zyskamy możliwość dzielenia się swoimi doświadczeniami z innymi specjalistami
    • Inne osoby będą mogły uzupełnić naszą pracę
  • Dokument taki - publicznie dostępny, może być przydatny również dla użytkowników w trakcie wyszukiwania i przeglądania kolekcji
  • Z czasem możemy zapomnieć dlaczego zdecydowaliśmy się na dane rozwiązanie. Wewnętrzne wytyczne będą doskonałą podstawą dla ciągłej rozbudowy obecnych i przyszłych kolekcji.
Oprócz powodów wymienionych powyżej, taki dokument może również zawierać przykładowe rekordy metadanych danej kolekcji razem z objaśnieniami. W trakcie realizacji projektu prawdopodobnie konieczna będzie weryfikacja początkowych założeń, a wytyczne będą ewoluować w miarę postępu projektu. Zanim przystąpi się do sporządzenia takiego dokumentu, należy przeanalizować praktyki stosowane w podobnych instytucjach. W Internecie można znaleźć wiele pomocnych zasobów:
  • Dokumenty techniczne Europeany [źródło]
    • Przykład opisu profilu aplikacyjnego:
      • "Europeana Data Model Documentation"
    • Przykład wytycznych dotyczących mapowania metadanych z istniejącego schematu do nowego:
      • “Metadata Mapping & Normalisation Guidelines for the Europeana Prototype”
  • Przykład wytycznych, określających zasady użycia Dublin Core Metadata Element Set z OAI-PMH
    • “Driver Guidelines for Content Providers” [źródło]
Wewnętrzne wytyczne, podobnie jak sam schemat, tworzy się przy okazji budowania nowej biblioteki cyfrowej. Działania te podejmowane są więc w miarę rzadko.

Co należy wiedzieć o Dublin Core Terms?

Wprowadzenie

W tym rozdziale będzie można lepiej poznać schemat metadanych Dublic Core Terms (DC Terms), który znany jest również jako kwalifikowany Dublin Core (w odróżnieniu od prostego DC czyli Dublin Core Metadata Element Set). Użytkownik kompendium będzie mógł dowiedzieć się więcej na temat roli każdego z elementów i zapoznać się z przykładowymi opisami. Standardy Dublin Core Metadata Element Set (DCMES) i jego rozszerzona wersja - Dublin Core Terms - są postrzegane jako rozwiązanie podstawowe w przypadku wielu różnych aplikacji. Ze względu na szerokie zastosowanie schemat ten jest bardzo ważny w kontekście interopracyjności. Jeśli dany projekt zdecyduje się na stosowanie innego standardu niż Dublin Core, prawdopodobnie i tak będzie konieczne przygotowanie wersji metadanych zgodnej z Dublin Core na potrzeby dalszego przekazywania danych. W przypadku małych instytucji kultury Dublin Core jest dobrym rozwiązaniem, ponieważ jest prosty, ale mimo to pozwala na tworzenie rozbudowanych opisów. Dzięki temu, że jest szeroko stosowany dostępne jest wiele darmowych opracowań i przykładów jego zastosowań.

Wprowadzenie do Dublin Core

Standard DCMES [źródło] powstał w wyniku dyskusji, która miała miejsce w 1995 w amerykańskim Dublinie w stanie Ohio. Ta inicjująca debata oraz dalsze prace, doprowadziły do stworzenia specyfikacji Dublin Core Metadata Element Set (DCMES). DCMES jest obecnie rozwijany przez Dublin Core Metadata Initiative (DCMI), która jest również zaangażowana w inne działania związane głównie z ustalaniem dobrych praktyk w zakresie metadanych. “Początkowym celem standardu Dublin Core było zdefiniowanie zestawu elementów, które mogłyby być używane do opisu zasobów sieciowych przez ich twórców. W obliczu ogromnego przyrostu zasobów elektronicznych i niemożności ich profesjonalnego skatalogowania przez bibliotekarzy, celem było zdefiniowanie kilku elementów i pewnych prostych reguł, które mogłyby być stosowane przy katalogowaniu przez laików.” [źródło]. DCMES miał być prosty i zwięzły dedykowany przede wszystkim dla dokumentów dostępnych w sieci np. stron WWW. Z czasem katalogujący zaczęli używać go również do materiałów innego typu. Oryginalna specyfikacja zawierała 13 elementów, ostatecznie ich liczbę, która obowiązuje do dziś, rozszerzono do 15: Tytuł, Twórca, Temat i słowa kluczowe, Opis, Wydawca, Współtwórca, Data, Typ zasobu, Format, Identyfikator zasobu, Źródło, Język, Relacja, Zakres oraz Prawa własności. Od 2003 r. DCMES jest standardem ISO. Jest to widocznym dowodem jego szerokiego uznania jako ważnego rozwiązania w zakresie metadanych.

Jak wyglądają metadane Dublin Core?

Poniżej przedstawiono przykład prostego rekordu metadanych. Pochodzi on z dokumentu “Using Dublin Core” [źródło]. Twórca: Rose Bush Tytuł: A Guide to Growing Roses Opis: Describes process for planting and nurturing different kinds of rose bushes. Data: 2001-01-20 Specyfikacja DCMES podaje dokładną interpretację powyższych pól (względnie etykiet) oraz to, jakie informacje powinny one zawierać.
  • Twórca zawiera informację o jednostce głównie odpowiedzialnej za stworzenie treści zasobu.
  • Tytuł jest nazwą zasobu.
  • Opis jest wyliczeniem zawartości treści zasobu.
  • Data jest związana z wydarzeniem w okresie istnienia zasobu.
Wszystkie elementy DCMES są opcjonalne i mogą być powtarzane (np. aby uwzględnić dwóch twórców). Podczas tworzenia metadanych DCMES powinno się pamiętać o zasadzie jeden do jednego, stosowanej we wszystkich specyfikacjach Dublin Core. Zasada ta mówi, że jeden rekord metadanych może opisywać tylko jeden zasób. Co to oznacza w praktyce? Najprostszą i najważniejszym wnioskiem wynikającym z  tej zasady jest to, że należy zwrócić uwagę na rozróżnienie między informacjami na temat fizycznych właściwości oryginalnego obiektu i jego cyfrowej wersji. Mimo że treści intelektualne są takie same, pozostałe właściwości tych dwóch zasobów się różnią. Na przykład w przypadku oryginalnego obiektu nośnikiem będzie obraz olejny na płótnie, dla obrazu cyfrowego będzie to format JPG. Poniżej znajduje się lista innych różnic między metadanymi związanymi z obiektem fizycznym i jego cyfrowym odpowiednikiem.
  • Format
    • Obiekt fizyczny: waga i rozmiar malowidła,
    • Obraz cyfrowy: wielkość (waga) i rozdzielczość pliku JPG,
  • Typ
    • Obiekt fizyczny: obraz olejny,
    • Wersja cyfrowa: obraz JPG,
  • Data
    • Obiekt fizyczny: data namalowania obrazu,
    • Wersja cyfrowa: data wykonania cyfrowej reprodukcji,
  • Twórca
    • Obiekt fizyczny: znany malarz,
    • Wersja cyfrowa: osoba, która wykonała obraz cyfrowy.
Te różnice mogą być przyczyną poważnych problemów. Idealnym rozwiązaniem powinno być stworzenie po jednym rekordzie DCMES dla obiektu oryginalnego i dla kopii cyfrowej. W tej sytuacji mimo, że oba rekordy będą różne, większość informacji będzie się powtarzała, co też nie jest dobre. Z praktycznego punktu widzenia połączenie obu rekordów metadanych jest bardzo kuszące.

Wprowadzenie do Dublin Core (DCMES)

DCMES jest prostym schematem metadanych, a jego zastosowanie w chwili obecnej wykracza poza opisy samych tylko zasobów sieciowych. Wraz z jego szerokim rozpowszechnieniem się, niektórzy eksperci zaczęli wymagać bardziej strukturalnego podejścia. W odpowiedzi na te żądania DCMI stworzyło rozszerzony format DCMES nazwany Dublin Core Metadata Terms (DC Terms). W specyfikacji tej określono zestaw kwalifikatorów, które umożliwiają uszczegółowienie informacji przechowywanych w rekordach metadanych.
Jaki był cel tego poszerzenia? “Uściślenie elementów pozwala zawęzić lub uczynić bardziej precyzyjnym znaczenie danego elementu. Uściślony element zachowuje znaczenie elementu podstawowego, ale jednocześnie ma bardziej ograniczony zakres. Wiodąca reguła dla kwalifikacji elementów Dublin Core, znana potocznie jako "zasada Dumb-Down" (Dumb-Down Principle), [źródło] mówi, że aplikacja, która nie rozumie określonego elementu uściślonego powinna móc zignorować ten kwalifikator i traktować wartość danego podelementu tak, jakby był on nieuściślonym (szerszym) elementem. Może to skutkować pewnym zmniejszeniem szczegółowości, ale pozostała wartość elementu (bez kwalifikatora) powinna wciąż być generalnie poprawna i przydatna dla celów wyszukiwania.” [źródło].Element "Data" (date) jest tu dobrym przykładem. W podstawowym (nieuściślonym) zestawie Dublin Core jest tylko jedno pole przeznaczone do przechowywania wszystkich informacji na temat wszystkich dat związanych z danym obiektem. W DC Terms dodano 8 uściśleń do oryginalnego pola Data: Data udostępnienia (available), Data utworzenia (created), Data przyjęcia (dateAccepted), Data copyright (dateCopytrighted), Data złożenia (dateSubmitted), Data wydania (issued), Data modyfikacji (modified), Data ważności (valid). Uściślenia te nie wyczerpują wszystkich możliwości w zakresie dat powiązanych z obiektem lub jego zawartością, ale dzięki wzbogaconej strukturze informacja przechowywana w metadanych może być bardziej zrozumiała przez programy komputerowe. W przypadku gdy dany program nie wie jakie jest znaczenie poszczególnych kwalifikatorów może je zignorować i traktować przypisane do nich wartości tak jakby były przypisane do standardowego pola Data.
Elementy pochodzące ze schematu Dublin Core są wytłuszczone. [W nawiasach podano oryginalne angielskie brzmienia nazw terminów]
  • Tytuł (title)
    • Wariant tytułu (alternative)
  • Twórca (creator)
  • Temat (subject)
  • Opis (description)
    • Abstrakt (abstract)
    • Spis treści (tableOfContents)
  • Wydawca (publisher)
  • Współtwórca (contributor)
  • Data (date)
    • Data udostępnienia (available)
    • Data utworzenia (created)
    • Data przyjęcia (dateAccepted)
    • Data copyright (dateCopytrighted)
    • Data złożenia (dateSubmitted)
    • Data wydania (issued)
    • Data modyfikacji (modified)
    • Data ważności (valid)
  • Typ (type)
  • Format (format)
    • Rozmiary (extent)
    • Nośnik (medium)
  • Identyfikator (identifier)
    • Cytata bibliograficzna (bibliographicCitation)
  • Źródło (source)
  • Język (language)
  • Powiązania (relation)
    • Zgodny z (conformsTo)
    • Ma format (hasFormat)
    • Ma część (hasPart)
    • Ma wersję (hasVersion)
    • Jest w formacie (isFormatOf)
    • Jest częścią (isPartOf)
    • Ma odniesienie w (isReferencedBy)
    • Zastąpiony przez (isReplacedBy)
    • Jest wymagany przez (isRequiredBy)
    • Jest wersją (isVersionOf)
    • Odniesienia (references)
    • Zastępuje (replaces)
    • Wymaga (requires)
  • Zakres (coverage)
    • Zakres przestrzenny (spatial)
    • Zakres czasowy (temporal)
  • Właściciel praw (rightsHolder)
  • Prawa (rights)
    • Prawa dostępu (accessRights)
    • Licencja (license)
  • Metoda uzupełniania zbioru (accrualMethod)
  • Częstotliwość uzupełniania zbioru (accrualPeriodicity)
  • Reguły uzupełniania zbioru (accrualPolicy)
  • Pochodzenie (provenance)
  • Odbiorcy (audience)
    • Poziom edukacyjny odbiorcy (educationLevel)
    • Pośrednik (mediator)
  • Metoda szkolenia (instructionalMethod)

Zastosowanie Dublin Core Terms

Opis elementów specyfikacji DC Terms jest z reguły bardzo ogólny. Dostępne są liczne dokumenty pomocnicze, np. “Using Dublin Core – The elements” lub "Using Dublin Core - Dublin Core Qualifiers". Oprócz formalnych dokumentów wydanych przez Dublin Core Metadata Initiative istnieją również inne źródła, z których można dowiedzieć się jak dostosować standard Dublin Core do określonych rodzajów zasobów i dziedzin. W poprzednich rozdziałach czytelnik kompendium mógł zapoznać się ze strukturami danych dla konkretnych zastosowań i zaleceniach dotyczących wewnętrznych metadanych. W niniejszej części, wśród wielu rodzajów zastosowań określonych dla formatu Dublin Core, znajdzie się również kilka odniesień do specyfikacji Europeana Data Model (EDM). Jest to dedykowana specyfikacja stworzona dla celów Europeany - Europejskiego muzeum cyfrowego, biblioteki i archiwum. EDM jest opiera się o DC Terms, przy czym uszczegółowiony został opis kilku pól oraz dodane elementy w celu zapewnienia określonych możliwości przeszukiwania w portalu Europeany. Niniejsza część jest w większości oparta o wspomniane dokumenty. Większa część przykładów pochodzi z dokumentu “Using Dublin Core – The elements” [źródło]. W opisie terminów znajduje się część z uwagami, których można użyć jako podstawy własnych wytycznych dotyczących tworzenia metadanych w projekcie. Tytuł (title) Element ten powinien zawierać nazwę nadaną danemu zasobowi. Zwykle element Tytuł (title) będzie nazwą, pod jaką dane źródło jest formalnie znane. W przypadku wszelkich wątpliwości dotyczących tytułu, należy powtórzyć ten element i w kolejnych powtórzeniach zawrzeć warianty tytułu. Uwagi:
  • Przy opisywaniu zdigitalizowanej książki należy użyć tytułu z pierwszej strony okładki oryginalnej książki
  • W przypadku alternatywnych tytułów, w szczególności jego tłumaczeń i skrótów, należy użyć kwalifikatora Wariant tytułu (alternative).
Przykłady:
  • Tytuł=”A Pilot's Guide to Aircraft Insurance”
  • Tytuł=”The Sound of Music”
  • Tytuł=”Digital repositories for small memory institutions”
Wariant tytułu (alternative) Jest to uszczegółowienie elementu Tytuł, które zawiera wszelkie formy tytułu używane jako zamienniki lub warianty formalnego tytułu zasobu. Może zawierać następujące informacje:
  • skróconą wersję tytułu,
  • pełną formę tytułu, zapisaną z użyciem skrótów lub liczb,
  • tytuł równoległy,
  • prawidłową wersję tytułu, jeśli w oryginalnym znajduje się błąd,
  • uwspółcześnioną wersję starego tytułu,
  • tytuł, pod którym źródło jest powszechnie znane,
  • wszelką inną formę tytułu, zwiększającą szansę wyszukania obiektu.
Uwagi:
  • Jeśli element ten nie jest używany, powyższe informacje mogą być zawarte w polu Opis (description)
Przykłady:
  • Wariant tytułu="AMA newsletter"
    • tytuł oryginalny to "American Meteorological Association newsletter"
  • Wariant tytułu="Ocho semanas"
    • hiszpańska wersja oryginalnego tytułu "Eight weeks" (Osiem tygodni)
  Temat (subject) Element ten przechowuje informację o zawartości tematycznej zasobu. W większości przypadków element Temat jest określany za pomocą słów kluczowych, fraz kluczowych lub kodów klasyfikacyjnych. Zaleca się użycie jakiegoś rodzaju słownika kontrolowanego dla tego elementu. Uwagi:
  • Aby określić zakres przestrzenny lub czasowy zasobu, należy użyć elementu Zakres (coverage).
  • Jeśli tematem jest osoba lub instytucja, należy użyć tej samej formy, jak w przypadku pola Twórca (creator).
  • Jeśli używa się formalnych identyfikatorów klasyfikacyjnych, należy dodać również formę opisową
    • np. I01.451.617 jest identyfikatorem z MeSH dla hasła Usługi pocztowe (Postal Service)
  • Terminy z poszczególnych słowników powinny być umieszczane w odrębnych powtórzeniach pola Temat.
Przykłady:
  • Temat="Aircraft leasing and renting"
  • Temat="Dogs" (Psy)
  • Temat="Olympic skiing" (Narciarstwo olimpijskie)
  • Temat="2nd World War", (Druga Wojna Światowa)
  • Temat="Art and War" (Sztuka i Wojna)
 
Opis (description) Element ten powinien odzwierciedlać treść zasobu. Może on zawierać abstrakt, spis treści, lub opis zawartości zapisany swobodnym tekstem. Opis jest bogatym źródłem informacji dla przyszłych użytkowników i pełni ważną rolę przy wyszukiwaniu zasobów. Pole to powinno być wypełnione jeśli dostępna jest dostateczna ilość informacji. Uwagi:
  • W polu Opis nie należy umieszczać żadnych znaczników HTML!
  • Pola tego nie należy mylić z polem Format.
Przykłady:
  • Opis = "Ilustrowany przewodnik po oznakowaniu lotnisk i stosowanych sygnałach świetlnych, ze szczególnym uwzględnieniem systemów zarządzania i kontroli ruchu naziemnego dla lotnisk o słabych warunkach widoczności."
  • Opis = "Teachers Domain jest biblioteką multimedialną dla nauczycieli szkół podstawowych i ponadpodstawowych, opracowaną przez WGBH dzięki finansowaniu przez National Science Foundation jako część inicjatywy National Science Digital Library. Witryna oferuje dużą ilość zasobów do wykorzystania w czasie lekcji, jak również materiały do rozwoju zawodowego, dostępne online oraz zestaw narzędzi umożliwiających nauczycielom zarządzanie, komentowanie i dzielenie się materiałami wykorzystywanymi w nauczaniu szkolnym."
Uszczegółowienia elementu Opis: Spis treści (tableOfContents) i Abstrakt (abstract) Oba te elementy uszczegóławiają zawartość pola Opis. Jeśli dany zasób ma spis treści, może on być wprowadzony w elemencie Spis treści (tableOfContents). Może to zapewnić nowe możliwości w zakresie indeksowania i prezentacji metadanych. Abstrakt zawiera streszczenie treści zasobu. Jako że formalne abstrakty są zwykle dostarczane z większością publikacji naukowych, wydaje się na miejscu ich umieszczenie w metadanych. W większości przypadków element Opis jest rodzajem abstraktu, ale w przypadku bardziej formalnych abstraktów bardziej odpowiednie może wydać się ich umieszczenie w odpowiednim elemencie. Przykłady:
  • Spis treści = "Introduction; Vertebrates; Invertebrates; Molluscs"
  • Abstrakt = "This article describes the work of the IFB Chaos Committee, including a summary of its major findings."
  • Abstrakt = "Illustrated guide to airport markings and lighting signals, with particular reference to SMGCS (Surface Movement Guidance and Control System) for airports with low visibility conditions."
  Rodzaj (type) W polu tym należy umieścić informację na temat typu lub rodzaju zawartości zasobu. Pole Rodzaj zawiera terminy opisujące ogólne kategorie, funkcje, gatunki lub poziomy agregacji dla treści. W przypadku tego pola zawsze należy używać słowników kontrolowanych, np. słownika typów DCMI (DCMI Type vocabulary) [źródło] lub adekwatnego słownika zgodnie z konwencją przyjętą danej bibliotece cyfrowej. Aby opisać fizyczne lub cyfrowe wersje zasobu, należy użyć elementu Format. Uwagi:
  • Jeśli zasób jest złożony z obiektów o różnych typach, wszystkie typy występujące w zasobie należy wprowadzić jako osobne wartości tego elementu.
  • Ponieważ różne społeczności dziedzinowe mogą używać różnych słowników, najlepszą praktyką aby zapewnić interoperacyjność jest podanie co najmniej jednego typu ogólnego ze Słownika typów DCMI, oprócz użycia terminów stosowanych w danej dziedzinie
Przykłady:
  • Elektroniczne katalogi wystaw dzieł sztuki mogą być opisane używając następujących wartości:
    • Rodzaj="Obraz", Rodzaj="Tekst", Rodzaj="Katalog wystawy"
    • Pierwsze dwa terminy zostały wzięte ze słownika typów DCMI, trzeci pochodzi z innego źródła.
  • Multimedialne programy edukacyjne z interaktywnymi zadaniami mogą być opisane w następujący sposób:
    • Rodzaj="Obraz", Rodzaj="Tekst", Rodzaj="Oprogramowanie", Rodzaj="Zasób interaktywny"
    • Pierwsze trzy terminy zostały wzięte ze słownika typów DCMI, ostatni z innego, nieznanego źródła.
  Źródło (source) Element ten powinien wskazywać zasób, z którego pochodzi opisywany obiekt. Opisywany zasób może wywodzić się z powiązanego zasobu częściowo lub w całości. Zalecaną najlepszą praktyką jest identyfikacja powiązanego źródła za pomocą zestawu znaków zgodnego z formalnym systemem identyfikacji. Przykłady:
  • Źródło = "RC607.A26W574 1996"
    • gdzie "RC607.A26W574 1996" jest sygnaturą drukowanej wersji zasobu, z której została utworzona opisywana skanowana wersja
  • Źródło = “http://dl.psnc.pl/biblioteka/publication/286”
Powiązanie (relation) Pole Powiązanie przechowuje informacje na temat powiązanych zasobów. Jako że istnieje ogromna liczba możliwych rodzajów relacji, część z nich została uwzględniona, a wartości przechowywane w tym polu mogą być uszczegółowione. Zaleca się użycie któregoś z formalnych systemów identyfikacji, takich jak URI, ISBN lub ISSN. Uwagi:
  • W zależności od rodzaju powiązania może ono obejmować więcej niż jeden zasób.
    • Dla przykładu: jeśli obiekt B jest częścią obiektu A oznacza to, że obiekt A zawiera w sobie obiekt B. Metadane obu zasobów muszą zawierać więc informację o tym powiązaniu.
Przykłady:
  • Powiązanie używane jest do wskazania, że dany obiekt jest jedną z wersji utworu danego artysty:
    • Tytuł="Candle in the Wind"
    • Temat="Diana, Księżna Walii"
    • Data="1997"
    • Twórca="John, Elton"
    • Typ="dźwięk"
    • Opis="W hołdzie dla zmarłej księżnej."
    • Powiązanie="Elton John's 1976 song Candle in the Wind"
  • Powiązanie jest używane do wskazania, że dany zasób odnosi się do innego obiektu
    • Tytuł="Morgan's Ancient Society"
    • Powiązanie="RC607.A26W574 1996 "
Uszczegółowienia elementu Powiązanie Większość uszczegółowień elementu Powiązanie opisuje relacje dwukierunkowe, np. Jest częścią (isPartOf) i Ma część (hasPart). Nie jest wymagane opisywanie obu obiektów wchodzących w taką relację, jednak dostarczenie takiej informacji może być przydatne. Czasem jednak jedna strona relacji jest ważniejsza niż druga, np. trudno sobie wyobrazić uwzględnienie w metadanych wszystkich obiektów, które cytują popularny podręcznik. Częściej inne zasoby będą wskazywać na dany podręcznik jako źródło referencji. W terminach metadanych DCMI zdefiniowano następujące uszczegółowienia elementu Powiązanie:
  • "Jest wersją" (isVersionOf), "Ma wersję" (hasVersion)
    • Używane do opisania sytuacji, w której jeden obiekt jest wersją innego obiektu.
    • Inna wersja zakłada raczej istotne różnice w treści niż zmianę formatu.
  • Zastąpiony przez (isReplacedBy), Zastępuje (replaces)
    • W przypadku dostępności wielu wersji danego zasobu, uszczegółowienia Zastąpiony przez iZastępuje mogą być użyte do wskazania użytkownikom najbardziej właściwej, aktualnej wersji.
  • "Jest wymagany przez" (isRequiredBy), Wymaga (requires)
    • Elementy te opisują zasób, który jest potrzebny opisywanemu zasobowi do prawidłowego jego działania, dostarczenia lub zachowania spójności.
    • Element Wymaga wydaje się być bardziej przydatny spośród tych dwóch elementów.
  • "Jest częścią" (isPartOf), "Ma część" (hasPart)
    • Opisywany zasób stanowi fizyczną lub logiczną część powiązanego zasobu
    • Ta para elementów pełni istotną rolę przy opisywaniu relacji typu rodzic - dziecko (parent-child relationship).
  • "Ma odniesienie w" (isReferencedBy), Odniesienia (references)
    • W zasobie znajduje się odniesienie do opisywanego zasobu, jest on cytowany lub w inny sposób wskazywany.
    • Elementy te mogą być użyte do wskazania artykułu na temat opisywanego zasobu np. recenzji, parodii przemówienia, odnoszącego się do oryginału, itp.
  • "Jest w formacie" (isFormatOf), "Ma format" (hasFormat)
    • Elementy te używane są do wskazania użytkownikom na różnych formatów danego obiektu; należy zaznaczyć, że zawartość powiązanych obiektów musi być taka sama.
  • "Zgodny z" (conformsTo)
    • Odniesienie do standardu, do którego stosuje się zasób.
Uwagi:
  • W przypadku wszystkich uszczegółowień elementu Powiązanie można użyć ciągu znaków lub identyfikatora URI.
  Zakres (coverage) Zakres zawartości zasobu; Element ten zwykle zawiera lokalizację przestrzenną (nazwę miejsca lub współrzędne geograficzne), okres czasu (etykietę okresu, datę lub zakres dat) lub jurysdykcję (np. nazwę jednostki administracyjnej). Jeśli to możliwe należy używać wartości ze słowników kontrolowanych, takich jak na przykład tezaurus nazw geograficznych Thesaurus of Geographic Names [źródło]. Tam gdzie to ma zastosowanie, powinno się stosować raczej nazwy miejsc lub okresów czasu zamiast identyfikatorów numerycznych, takich jak współrzędne lub daty. W przypadku użycia tego elementu do informacji na temat zasięgu przestrzennego, jak i czasowego, należy zwrócić uwagę na spójność informacji, która powinna być zrozumiała dla użytkowników, szczególnie w celu zapewnienia interoperacyjności w sytuacji, gdy nie jest zapewnione zaawansowane wyszukiwanie według położenia geograficznego lub okresów czasowych. Uwagi:
  • Należy zapoznać się ze specyfikacjami DCMI Period (do wyrażenia informacji o przedziałach czasowych), DCMI Box (dla wyrażenia informacji własnościach przestrzennych) lub DCMI Point (dla wyrażenia położenia geograficznego).
Przykady:
  • Zasięg = “1995-1996”
  • Zasięg="XVII wiek"
  • Zasięg="Upstate New York"
  • Zasięg=”name=Perth, W.A.; east=115.85717; north=-31.95301”
    • Przykład wartości zgodnej ze specyfikacją DCMI Point.
  • Zasięg=”name=The Great Depression; start=1929; end=1939;”
    • Przykład wartości zgodnej ze specyfikacją DCMI Period.
Uszczegółowienia elementu Zakres - Zakres przestrzenny (spatial) i Zakres czasowy (temporal) Zakres jest jednym z bardzo ogólnych atrybutów, który można uszczegółowić za pomocą dwóch elementów: Zakres przestrzenny i Zakres czasowy. Charakterystyka przestrzenna może zawierać nazwy geograficzne, współrzędne lub inne powszechnie stosowane wartości georeferencyjne. Zaleca się użycie standardowych schematów lub słowników kontrolowanych, np. specyfikacji DCMI Box (wykaz obszarów) lub DCMI Point (wykaz miejsc oznaczonych współrzędnymi geograficznymi). Charakterystyka czasowa dotyczy tych aspektów czasu, które odnoszą się do zawartości opisywanego zasobu, a nie do wydarzenia związanego z samym zasobem. Zasób może dotyczyć na przykład pewnych aspektów historii antycznej. Wartości mogą być ciągami znaków lub wartościami zakodowanymi (zapisany) zgodnie z określoną składnią. Dokładne zalecenia dotyczące zapisywania charakterystyki czasowej można znaleźć w specyfikacji DCMI Period Encoding Scheme. Przykłady:
  • Zakres przestrzenny="Chicago, Ill."
  • Zakres przestrzenny="Lat: 44 00 00 S Long: 068 00 00 W Name: Patagonia"
    • Dla wyjaśnienia:
      • Szer. geogr : 44 00 00 S
      • Dług. geogr: 068 00 00 W
      • Nazwa: Patagonia
  • Zakres przestrzenny=”name=Perth, W.A.; east=115.85717; north=-31.95301”
    • Przykład wartości zgodnej ze specyfikacją DCMI Point.
  • Zasięg czasowy= "Jurassic Period" (Okres jurajski)
  • Zasięg czasowy="Twentieth Century" (Dwudziesty wiek)
  • Zasięg=” name=The Great Depression; start=1929; end=1939;”
    • Przykład wartości zgodnej ze specyfikacją DCMI Period.
    • Dla wyjaśnienia:
      • nazwa = Wielki kryzys
      • początek = 1929
      • koniec = 1939
  Twórca (creator) Twórca jest jednostką w głównej mierze odpowiedzialną za powstanie zawartości intelektualnej zasobu. Może to być osoba, organizacja lub usługa. Uwagi:
  • Twórcy powinni być wymieniani osobno, najlepiej w tej samej kolejności, w jakiej występują w danej publikacji.
  • W przypadku nazw osobowych powinno się podać najpierw nazwisko, następnie imię.
  • Tytuły naukowe należy pominąć.
  • Twórców w mniejszym stopniu odpowiedzialnych za stworzenie zasobu można wymienić używając pola Współtwórca (contributor).
  • W przypadku organizacji, w których istnieje jasno określona hierarchia, należy wymienić jednostki danej organizacji od największej do najmniejszej, oddzielając je kropkami i odstępem.
  • Jeśli Twórca i Wydawca są tacy sami, nie należy powtarzać nazwy w polu Wydawca.
  • Jeśli rodzaj odpowiedzialności jest niejasna, zalecaną praktyką jest użycie pola Wydawca dla organizacji i Twórca dla osób.
  • Można rozważyć użycie jednego z zestawów haseł wzorcowych, np. Library of Congress Authorities.
Przykłady:
  • Twórca="Shakespeare, William"
  • Twórca="Wen Lee"
  • Twórca="Hubble Telescope"
  • Twórca="Internal Revenue Service. Customer Complaints Unit"
  Wydawca (publisher) Jednostka odpowiedzialna za udostępnienie zasobu. Może to być osoba, organizacja lub usługa. Zwykle jednostkę tę powinna określać nazwa Wydawcy. Uwagi:
  • Jeśli Twórca jest taki sam, jak Wydawca, nie należy powtarzać jego nazwy w polu Wydawca.
  • Więcej uwag - patrz sekcja dotycząca pola Twórca.
Przykłady:
  • Wydawca="Poznań University of Technology"
  • Wydawca="Tim O'Reilly"
  Odbiorcy (audience) Element Odbiorcy jest pierwszym z siedmiu elementów obecnych tylko w kwalifikowanym Dublin Core. Oznacza, że nie istnieje bardziej ogólny odpowiednik tych elementów w prostym Dublin Core. Informacje umieszczone w tych polach zostaną usunięte w przypadku sprowadzenia opisu do zwykłego Dublin Core. Element ten powinien być używany na określenie odbiorców, dla których dany zasób jest przeznaczony. Aby informacja ta była możliwa do efektywnego wykorzystania należy używać słów i fraz ze słowników kontrolowanych (formalnych lub nieformalnych). Przykłady:
  • Odbiorcy="studenci uniwersytetów technicznych"
  • Odbiorcy="nauczyciele szkół podstawowych"
  • Odbiorcy="dzieci głuchonieme"
  Pochodzenie (provenance) Informacje na temat wszelkich zmian własności lub nadzoru nad zasobem od momentu jego wytworzenia, które są ważne dla określenia jego autentyczności, spójności i interpretacji. Przykłady:
  • Pochodzenie="Kopia dawniej w posiadaniu Lecha Wałęsy."
  • Pochodzenie="Skradzione w 2002; odzyskane przez muzeum w 2003."
  Właściciel praw (rightsHolder) Jednostka (osoba lub instytucja) zarządzająca prawami autorskimi do obiektu lub będąca ich posiadaczem. Zaleca się użycie identyfikatora URI lub formalnej nazwy właściciela praw autorskich. Uwagi:
  • Ponieważ osoby i organizacje zwykle nie mają przypisanych identyfikatorów URI, o ile będą w posiadaniu praw autorskich do zasobu będą ich nazwy osobowe czy instytucjonalne zapisane będą w wersji tekstowej.
  • Osoby i organizacje czasem mają strony internetowe, ale adresów URL tych stron zwykle nie można użyć w tym kontekście, ponieważ nie identyfikują one w jasny sposób tych osób lub organizacji, tylko lokalizację ich stron internetowych.
Przykłady:
  • Właściciel praw="Stephen King"
  • Właściciel praw="Politechnika Poznańska"
  Metoda szkolenia (instructionalMethod) Element ten powinien być użyty, jeśli dany zasób został opracowany w celu wsparcia określonej metody lub procesu będącego źródłem wiedzy, poglądu lub umiejętności. Pole Metoda szkolenia powinno być użyte do przechowywania nazwy metody, w której obiekt może być stosowany. “Pole Metoda szkolenia zwykle zawiera sposoby prezentowania materiałów szkoleniowych lub przeprowadzenia szkolenia, wzorce interakcji między uczniami i nauczycielami, mechanizmy pomiaru poziomu umiejętności grup i poszczególnych uczniów. Pole to może uwzględniać wszelkie aspekty instrukcji i procesu nauczania od planowania i wdrożenia przez ewaluację i informację zwrotną.” [źródło] Uwagi:
  • W celu osiągnięcia najlepszych rezultatów należy użyć terminów ze słowników kontrolowanych.
Przykłady:
  • Metoda szkolenia="Nauczanie eksperymentalne"
  • Metoda szkolenia="Obserwacja"
  • Metoda szkolenia="Instrukcja dla dużej grupy"
  Metoda uzupełniania zbioru (accrualMethod), Częstotliwość uzupełniania zbioru (accrualPeriodicity), Reguły uzupełniania zbioru (accrualPolicy) Wszystkie trzy wymienione elementy dotyczą kolekcji, których dany obiekt jest częścią. Metoda uzupełniania zbioru opisuje metody, według których elementy są dodawane do kolekcji. Częstotliwość uzupełniania zbioru wyjaśnia jak często obiekty będą dodawana do kolekcji. Reguły uzupełniania zbioru opisują sposób dodawania zbiorów do kolekcji. Uwagi:
  • W przypadku wszystkich trzech elementów powinno się używać słowników kontrolowanych.
Przykłady:
  • Metoda uzupełniania zbioru="Depozyt"
  • Metoda uzupełniania zbioru="Zakup"
  • Częstotliwość uzupełniania zbioru="Rocznie"
  • Częstotliwość uzupełniania zbioru="Nieregularnie"
  • Reguły uzupełniania zbioru="Aktywny"
  • Reguły uzupełniania zbioru="Zamknięty"