Polona/Labs

Standardy metadanych obiektów cyfrowych. Wymiana obiektów pomiędzy repozytoriami cyfrowymi. Cz. 1


    Aby w bibliotekach, archiwach lub muzeach możliwą była realizacja zadań takich jak:

    • digitalizacja zbiorów,
    • organizowanie i zarządzanie repozytorium cyfrowym,
    • długoterminowa archiwizacja i ochrona zbiorów cyfrowych przed ich utraceniem,
    • przekazywanie wykonanych zbiorów cyfrowych do innych repozytoriów,

    koniecznym jest zgromadzenie różnorodnych informacji dotyczących m.in. oryginałów obiektów poddanych digitalizacji, powstałych obiektów cyfrowych, szczegółowego opisu sposobu ich wykonania oraz użytych narzędzi i środków. Tak zebrane informacje – o każdym powstałym obiekcie cyfrowym – określane są jako „rekord metadanych” lub wprost „metadane obiektu cyfrowego”. Wykonywane są zazwyczaj podczas realizacji projektu digitalizacyjnego. W późniejszym okresie, podczas realizacji kolejnych zadań, a wyszczególnionych wyżej, ich zawartość może podlegać aktualizacji bądź rozbudowie. Dla potrzeb systemów informatycznych zarządzających bądź wspierających procesy digitalizacji, metadane zachowywane są w bazie danych. Dla potrzeb archiwizacji długoterminowej lub przekazywania obiektów cyfrowych do innych repozytoriów, metadane zachowywane są pod postacią plików tekstowych. Aby możliwym było automatyczne przetwarzanie tekstowych plików metadanych, koniecznym jest użycie zalecanych, uzgodnionych bądź wymaganych standardów metadanych, za pośrednictwem których takie pliki zostaną wykonane. Należy zauważyć, że nie jest tożsamym – wyłącznie zgromadzenie potrzebnych informacji dla wykonania plików metadanych oraz wyłącznie wykonanie plików metadanych w oparciu o już zgromadzone informacje. Często, działania te podzielone są pomiędzy koordynatora czy też opiekuna projektu digitalizacyjnego i dział informatyczny bądź partnera zewnętrznego, który takie pliki wykona. Uwaga ta powinna być uwzględniona podczas szczegółowego opracowywania kolejnych etapów procesu digitalizacji zbiorów.

    Metadane, których wykonania wymaga się dla każdego obiektu cyfrowego, złożone są z wielu informacji, różniących się wzajemnie co do ich zawartości, przeznaczenia i natury. Metadane obiektów cyfrowych dzielimy na cztery kategorie:

    • metadane deskryptywne (opisowe),
    • metadane administracyjno-techniczne,
    • metadane strukturalne oraz
    • techniczne metadane rozpoznanego tekstu.

    Kategoria metadanych administracyjno-technicznych złożona jest z czterech współtworzących ją kategorii:

    • metadane administracyjne,
    • metadane techniczne,
    • metadane konserwatorskie,
    • metadane praw i uprawnień udostępniania obiektu cyfrowego.

    Tylko tekstowe pliki metadanych zawierające zarówno metadane deskryptywne, strukturalne jak i administracyjno-techniczne pozwalają przekazywać obiekty cyfrowe pomiędzy repozytoriami w taki sposób, że możliwym jest:

    • automatyzacja procesu ich przekazywania,
    • jednoznaczna identyfikacja zawartości przekazanych obiektów cyfrowych,
    • jakościowo-ilościowa weryfikacja plików przekazanych obiektów cyfrowych.

    Zaleca się, by poza graficznymi plikami każdego obiektu cyfrowego, dla którego podczas digitalizacji wykonano operację optycznego rozpoznania zawartości tekstowej (OCR), wykonać również tekstowe pliki metadanych rozpoznanego tekstu. W kolejnych plikach rozpoznanego tekstu, wykonanych również wg odpowiednio uzgodnionego standardu metadanych, zachowuje się zazwyczaj zawartość tekstową pojedynczej strony zdigitalizowanego obiektu.

    Pomijając format MARC-21, wszystkie schematy (standardy) metadanych wyrażone są za pomocą języka XML. Tym samym, można przyjąć, że język XML stał się de facto standardem do reprezentowania metadanych zasobów cyfrowych. Zaleca się, by tekstowe pliki metadanych wykonywać wyłącznie w oparciu o kodowanie liternictwa UTF-8. W tak wykonanych plikach pierwszy wiersz posiada zazwyczaj postać:

    <?xml version=”1.0″ encoding=”UTF-8„?>

    lub podobną, np.:

    <?xml version=”1.0″ encoding=”UTF-8” standalone=”yes”?>

    Spośród dostępnych standardów metadanych przeznaczonych dla bibliotek i muzeów, dominującym czy też bardzo często wybieranym jest – opracowany w Bibliotece Kongresu USA (zwanej dalej LOC)- standard METS (Metadata Encoding and Transmission Standard). Oferowany jest obecnie w wersji nr 1.11. W Centrum Kompetencyjnym Biblioteki Narodowej (zwanym dalej CK BN), m.in. dla potrzeb przyjmowania obiektów cyfrowych od współpracujących z BN instytucji, METS jest standardem wymaganym. Tekstowe pliki metadanych, wykonane zgodnie z wymogami standardu METS, nazywane są plikami METS lub plikami METS obiektu cyfrowego. Standard METS, jako schemat metadanych oferuje wyłącznie środki do  zachowywania metadanych strukturalnych dotyczących obiektu cyfrowego. Jednocześnie, umożliwia dołączenie do pliku METS metadanych innych kategorii, których postać musi spełniać wymogi takiego standardu, który wykonawca pliku METS uzna za najbardziej właściwy i jednocześnie takiego, który akceptuje CK BN. Standardy metadanych – w oparciu o które – dołącza się do pliku METS metadane deskryptywne oraz administracyjno-techniczne, w dokumentacji dotyczącej schematu METS określane są terminem „schematy rozszerzenia” (extension schemas). Dodatkowo, wśród dostępnych schematów rozszerzenia, twórcy standardu METS wyróżniają „schematy zatwierdzone”. Określenie „schematy zatwierdzone” ani nie wyklucza, ani nie ogranicza możliwości użycia innych schematów rozszerzenia. W odniesieniu do metadanych deskryptywnych, schematami zatwierdzonymi są:

    Jedynym schematem zatwierdzonym dla metadanych administracyjno-technicznych jest standard

    Dla metadanych technicznych schematami zatwierdzonymi są

    Dla metadanych praw i uprawnień udostępniania obiektu cyfrowego, LOC obecnie rozwija schemat autorstwa Stanford University, który nie jest schematem zatwierdzonym:

    CK BN akceptuje wszystkie wyżej wymienione schematy zatwierdzone. Ponadto, w odniesieniu do metadanych deskryptywnych, akceptowanymi ze strony CK BN są : format MARC-21 oraz schemat PLMET (Dlibra_AVS).

    Jednym z wymogów przekazywania obiektów cyfrowych do CK BN jest określenie metadanych praw i uprawnień udostępniania obiektu cyfrowego, które w pliku METS znajdują się w obrębie elementu <rightsMD>. Zastosowanie dla tych metadanych schematu METSRights jako schematu rozszerzenia, wydaje się być propozycją godną polecenia.

    Analizując plik METS, bardzo łatwo ocenić, czy pewien użyty w nim schemat rozszerzenia jest schematem zatwierdzonym. Dla schematów zatwierdzonych, kod (skrót) określający nazwę schematu podawany jest jako wartość atrybutu MDTYPE. Taki kod musi być wybrany z listy dozwolonych wartości, określonych przez twórców METS. Przykładowo, metadane deskryptywne schematu zatwierdzonego deklarowane są następująco:

    <mets:dmdSec ID=”DM_MODS” STATUS=”current”>

    <mets:mdWrap MIMETYPE=”text/xml” MDTYPE=”MODS„>

    zaś jedna z kategorii metadanych administracyjno-technicznych:

    <mets:amdSec>

    <mets:techMD ID=”TMD.00DA65_RT”>

    <mets:mdWrap MIMETYPE=”text/xml” MDTYPE=”TEXTMD„>

    Poniżej przedstawiono przykład dołączania schematów rozszerzenia, które nie są schematami zatwierdzonymi:

    <mets:dmdSec ID=”DM_PLMET” STATUS=”current”>

    <mets:mdWrap MIMETYPE=”text/xml” MDTYPE=”OTHER” OTHERMDTYPE=”dlibra_avs„>

    analogicznie dołączana jest jedna z kategorii metadanych administracyjno-technicznych:

    <mets:amdSec>

    <mets:techMD ID=”RMD.00DA65″>

    <mets:mdWrap MIMETYPE=”text/xml” MDTYPE=”OTHEROTHERMDTYPE=”METSRIGHTS„>

    Nieprzestrzeganie przedstawionych powyżej sposobów dołączania schematów rozszerzenia powoduje, że wykonany plik METS z punktu widzenia wymogów schematu jest wadliwy. Obiekt cyfrowy, dla którego wykonano niewłaściwie plik METS, nie spełnia warunków odbioru przez CK BN.

    Schematy metadanych pozwalające zachować techniczne metadane rozpoznanego tekstu nie są schematami rozszerzenia METS. Tym samym termin „schemat zatwierdzony” w odniesieniu do tych schematów nie posiada zastosowania. Przyczyna takiego stanu jest oczywista. Techniczne metadane rozpoznanego tekstu nie są zachowywane w pliku METS. Jako pliki tekstowe wraz z plikami graficznymi tworzą obiekt cyfrowy. Dla metadanych rozpoznanego tekstu, najbardziej zaawansowanym, oferującym największą liczbę funkcjonalności jest schemat ALTO (The Analyzed Layout and Text Object XML Schema). Oferowany jest obecnie w wersji nr 3.1. Jest schematem wymaganym w CK BN.

    Schemat METS nie jest skomplikowany. W naturalny sposób pozwala grupować i porządkować zachowywane w plikach METS kategorie metadanych. W plikach METS zawsze występuje element główny <mets> (Root element) oraz do siedmiu podległych mu elementów wysokiego poziomu (Top-level element), często nazywanych sekcjami:

    • <metsHdr>
    • <dmdSec>
    • <amdSec>
    • <fileSec>
    • <structMap>
    • <structLink>
    • <behaviorSec>

    Elementowi <amdSec> podlegają cztery elementy:

    • <sourceMD>
    • <techMD>
    • <digiprovMD>
    • <rightsMD>

    Jedynym elementem, który musi wystąpić w pliku METS, jest element <structMap>. Wystąpienie w pliku METS pozostałych elementów jest opcjonalne. To, które z dostępnych elementów schematu zostaną umieszczone w pliku METS, zależy w głównej mierze od celu w jakim plik taki jest wykonywany lub wymagań strony, której wraz z plikami obiektu cyfrowego zostanie przekazany. Twórcy schematu zdecydowanie zalecają, by wykonywanie plików METS rozpoczynać od wykonania sekcji plików <fileSec>, a zatem od wykonania kompletnego zestawienia wszystkich plików, które dotyczą opisywanego obiektu cyfrowego. W kolejnym kroku zaleca się wykonanie co najmniej jednej sekcji <structMap> – struktury obiektu cyfrowego.

    Dla potrzeb wymiany obiektów cyfrowych pomiędzy repozytoriami jak i opisu nawet bardzo złożonych obiektów, sekcji metadanych <behaviorSec> zazwyczaj się nie używa. Nie jest też ona wymagana przez CK BN. Za pomocą tej sekcji m.in. kojarzy się pliki graficzne obiektu z określonymi aplikacjami (oprogramowaniem renderującym, przeglądarkami, …). Należy założyć, że dla tak powszechnych i popularnych formatów plików jak TIFF, PDF, JPEG, PNG lub JP2000, nie zajdzie potrzeba skorzystania z możliwości oferowanych w sekcji <behaviorSec>. Mając na uwadze powyższe, kolejność wystąpienia – w pliku METS – elementów wysokiego poziomu (sekcji), a tym samym i metadanych, które w tych sekcjach zostaną zachowane, jest następująca:

    W pliku METS wszystkie wystąpienia sekcji metadanych deskryptywnych oraz administracyjno-technicznych umieszcza się za sekcją nagłówka pliku <metsHdr>. Ostatnimi sekcjami w pliku METS są: sekcja plików <fileSec> i co najmniej jedna sekcja struktury <structMap> oraz <structLink>.

    Dla każdego schematu metadanych, który został użyty w pliku METS, wymaga się podania właściwej mu przestrzeni nazw (name space). Jest to internetowy adres strony udostępniającej plik typu XSD (XML Schema Definition). Plik ten zawiera zestaw definicji wszystkich elementów schematu, w tym typów wartości tych elementów (liczby, daty, tekst, wartości logiczne, …). Zaleca się, by przestrzenie nazw wszystkich schematów użytych w pliku METS deklarować jako wartości atrybutu xmlns=”… elementu głównego <mets> (drugi wiersz pliku METS):

    <mets xmlns=”http://www.loc.gov/mets/” xmlns:mods=”http://www.loc.gov/mods/v3″ …

    xsi:schemaLocation=”http://www.loc.gov/mets/ http://www.loc.gov/standards/mets/mets.xsd

    http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-3-6.xsd …” … >

    lub

    <mets:mets xmlns:mets=”http://www.loc.gov/mets/” xmlns:mods=”http://www.loc.gov/mods/v3″ …

    xsi:schemaLocation=”http://www.loc.gov/mets/ http://www.loc.gov/standards/mets/mets.xsd

    http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-3-6.xsd …” … >

    Deklarując przestrzeń nazw pewnego schematu, można nadać jej etykietę (przedrostek). Jest to zalecany zabieg, ponieważ znacznie podnosi czytelność, zwłaszcza obszernych plików METS złożonych nierzadko z co najmniej sześciu różnych schematów metadanych. Z reguły, treścią etykiety jest nazwa deklarowanego schematu np.: mets, mods, …, co przedstawiono powyżej.

    Sekcja plików <fileSec> czy też <mets:fileSec> przechowuje informacje o wszystkich plikach, które współtworzą opisywany obiekt cyfrowy. Najważniejszymi informacjami o pliku są: nazwa wraz z relatywną ścieżką dostępu oraz unikatowy identyfikator, za pośrednictwem którego możliwe jest odwoływanie do tego pliku. Sekcja ta wydaje się być najbardziej odpowiednią do zachowywania – podanych niżej – właściwości o każdym z plików:

    • Data utworzenia CREATED=”…
    • Rozmiar pliku podany w bajtach SIZE=”…
    • Wybrany algorytm, wg którego wyznaczono sumę kontrolną pliku CHECKSUMTYPE=”…
    • Wartość sumy kontrolnej CHECKSUM=”…
    • Typ MIME pliku MIMETYPE=”…

    Powyższe właściwości pliku można także określić za pośrednictwem metadanych administracyjno-technicznych PREMIS lub metadanych technicznych MIX. Ponieważ taki wybór wymaga większej ilości kodu w pliku METS, stąd rekomendacja, by właściwości pliku określać w sekcji <mets:fileSec>.

    Sekcja <mets:fileSec> posiada podległy jej element <mets:fileGrp>. Przykładowo, jeżeli obiekt cyfrowy złożony jest z plików macierzystych w formacie TIFF (pliki pierwotne), plików prezentacyjnych w formatach PDF i JPEG (pliki wtórne) oraz wykonano dla tego obiektu rozpoznanie zawartości tekstowej, którą zachowano w plikach ALTO (pliki wtórne), element <mets:fileGrp> w obrębie sekcji <mets:fileSec> wystąpi czterokrotnie (kolejno dla TIFF, PDF, JPEG i ALTO). Elementowi <mets:fileGrp> podlega z kolei element <mets:file>. Atrybutom tego elementu przypisuje się m.in. pięć właściwości pliku podanych wyżej. Nazwa pliku i sposób jej określenia zachowywany jest w elemencie lokalizatora plików (File Locator) <mets:FLocat>. Podlega on elementowi <mets:file> i może posiadać postać jak przedstawiono to poniżej:

     

    <mets:fileSec>

    <mets:fileGrp ID=”MFGrp” USE=”master file” ADMID=”AMD.Dscr.Grp_MF”>

    <mets:file  ID=”FID.06499E_MF” MIMETYPE=”image/tiff” SEQ=”12″ CREATED=”2017-12-04T08:58:46″

    ADMID=”AMD.Dscr.Dta_MF CMD.0DA65_MF TMD.06499E_MF AMD.06499E_MF”

    GROUPID=”Grp1″ SIZE=”6201282″ CHECKSUMTYPE=”MD5″

    CHECKSUM=”7723365D62AEE2D3199ADA08A2DDFC97″>

    <mets:FLocat xlink:href=”TIFF/0023697-12.tif” LOCTYPE=”URL” xlink:type=”simple”/> …

    W zależności od stosowanego oprogramowania, postać nazwy pliku wyrażona może być odmiennie. Przykładowo :

    <mets:FLocat xlink:href=”file://./TIFF/0023697-12.tif” LOCTYPE=”URL”/>

    <mets:FLocat xlink:href=”file:TIFF/0023697-12.tif” LOCTYPE=”URL” xlink:type=”simple”/>

    <mets:FLocat xlink:href=”TIFF/0023697-12.tif” LOCTYPE=”OTHER” OTHERLOCTYPE=”SYSTEM”/>

    <mets:FLocat xlink:href=”http://wimbp.Miasto.pl/Digi2018-02/TIFF/0023697-12.tif” LOCTYPE=”URL”/>

    Zgodnie z wymogiem CK BN, pliki obiektów cyfrowych na przekazywanym nośniku należy zapisać w taki sposób, by w sekcji <mets:fileSec> możliwym było zastosowanie wyłącznie odniesień lokalnych do każdego pliku obiektu cyfrowego, a zatem określenia wyłącznie nazwy tego pliku i jego relatywnej a nie bezwzględnej ścieżki dostępu. Tym samym, ostatni spośród przedstawionych przykładów elementu <mets:FLocat>, który nie jest odniesieniem lokalnym i jednocześnie zawiera adresowanie bezwzględne, nie może spełnić wymogu CK BN.

    W oparciu o informacje nt. sekcji <mets:fileSec>, można określić sposób zapisu plików obiektów cyfrowych na przekazywanym nośniku. Pliki każdego obiektu cyfrowego zapisywane są w oddzielnym folderze. W folderze tym zapisany będzie również plik METS. Ponieważ obiekt cyfrowy to zazwyczaj kolekcje plików pierwotnych i wtórnych, zapisuje się je nie wprost w folderze obiektu, lecz w jego podfolderach, których nazwy informują o formacie zachowywanych plików. Przykładową zawartość foldera obiektu przedstawiono poniżej:

    Powyższy przykład może odpowiadać obiektowi wydawnictwa zwartego. W przypadku wydawnictw ciągłych, kolejne obiekty cyfrowe umieszczone są w złożonej gałęzi folderów odpowiadającej strukturze tego wydawnictwa. W takim przypadku, folder obiektu cyfrowego przedstawić można:

    Widok powyższych dwóch przykładów, przedstawiony jako drzewko folderów przekazywanego nośnika, posiada postać:

    Jedną z najważniejszych kwestii dotyczących struktury folderów, jest nazwa folderu obiektu (wyd. zwarte) lub nazwa folderu obiektu złożonego (wyd. ciągłe). Tylko w jednym przypadku możliwe jest automatyczne generowanie setek lub tysięcy plików METS z zachowaniem zerowego prawdopodobieństwa błędu powiązania ich z odpowiadającymi im zawartością folderami obiektów. Jeżeli nazwy folderów będą „korespondować” lub odpowiadać wprost wartości pewnej metadanej, unikatowej przynajmniej w obrębie projektu digitalizacyjnego, możliwe jest automatyczne i precyzyjne powiązanie (dopasowanie) rekordu metadanych z folderem obiektu, a właściwie należałoby stwierdzić, tysięcy rekordów metadanych z tysiącami folderów obiektów. W przypadku przeciwnym, wskazanie powiązań „metadane obiektu – folder obiektu” wykonywane muszą być ręcznie. Powyższy warunek bardzo często spełnia numer sygnatury zdigitalizowanego obiektu. Proponuje się, by nazwami folderów obiektów (złożonych) były numery sygnatur, w których wszelkie separatory (ukośniki, dwukropki, …) zastąpiono np. znakiem podkreślenia lub spacją. Dla takiej propozycji, przykładowe drzewo folderów zawierające obiekt wyd. zwartego oraz obiekt wyd. ciągłego zilustrować można następująco:

    Przytoczona wartość elementu <mets:FLocat> pokazuje, że dla poprawnego określenia położenia plików obiektu cyfrowego istotne są jedynie lokalizacje podfolderów folderu obiektu (TIFF/, PDF/, ALTO/, …). Tym samym, ilość poziomów folderów nadrzędnych względem folderu obiektu nie jest istotna.  Przedstawiony powyżej przykład można rozszerzyć np. o poziom folderów „kwartał” pomiędzy poziomami „rok” i „numer wydania”. Można pomiędzy poziomami folderów „Sygnatura” i „Archiwum” dodać poziom folderów o nazwach „Czasopisma”, „Starodruki”, „Mapy”, … W obu tych przypadkach drzewko folderów nadal będzie spełniać wymogi CK BN przekazywanych obiektów cyfrowych.