W POSZUKIWANIU OBRAZU.
KILKA UWAG O MODELOWANIU BAZY DANYCH PROJEKTU „OBRAZ MODYFIKOWANY”
Katalogi wystaw, kolekcji lub aukcji dzieł sztuki, służące przede wszystkim zapisaniu faktu zgrupowania pewnych dzieł w konkretnym miejscu i czasie, zawierają zwykle różne dane, dotyczące wymienianych w nich dzieł. Często są to informacje bezcenne dla późniejszych badaczy, lecz ich sposób zapisu łączy się nieraz z daleko idącymi uproszczeniami. Choćby w powszechnie stosowanej formie, takiej jak w tym przypadku:
Jan Matejko (1838-1893), Bitwa pod Grunwaldem, 1878
O ile trudno tu mieć wątpliwości co do sposobu zapisu tytułu dzieła i jego autora, to podana data może już je budzić. Zgodnie z powszechnie przyjętą konwencją jest to data ukończenia dzieła. Ale czy rzeczywiście jest to data w jego historii najważniejsza? Może co najmniej równie ważna jest data powstania koncepcji obrazu albo rozpoczęcia nad nim pracy? Te wszystkie wydarzenia są istotne dla badacza jego historii i powinny zostać zapisane w rekordzie bazy danych, której celem jest zebranie możliwie pełnego zbioru informacji, dotyczących dzieła. Malowidło lub rzeźba, zwłaszcza jeśli ma jednego autora, jest dla twórcy bazy danych łatwiejszym wyzwaniem niż dzieło graficzne, tu bowiem w grę wchodzi stworzenie rysunku przygotowawczego, wykonanie matrycy, a następnie wytworzenie przy jej pomocy odbitek graficznych, i zdarzenia te mogą być odległe w czasie i przestrzeni. Co więcej, nie zawsze łatwo zidentyfikować rysownika, rytownika i wydawcę, a właściwie wydawców, matryce bowiem zmieniały właścicieli, podlegały modyfikacjom, a także były kopiowane (legalnie lub nie, z podaniem właściwych autorów kompozycji lub nie).
Projektując system komputerowy, którego zadaniem ma być gromadzenie informacji o dziełach sztuki, trzeba przewidzieć możliwość zapisu tego rodzaju zdarzeń, wszystkich ich uczestników i wszystkich przedmiotów powstałych w ich trakcie. Stworzenie kompletnego lub prawie kompletnego modelu danych takiej bazy przed rozpoczęciem jej tworzenia jest niezwykle istotne, bo wszystkie ewentualne późniejsze jego zmiany mogą oznaczać konieczność powtórnego wpisywania już raz wprowadzonych danych, a przynajmniej ich, czasochłonnego i obarczonego ryzykiem błędu, przeredagowania.
Na szczęście nie trzeba było tworzyć takiego modelu od zera. Jako podstawa do dalszych prac został przyjęty model danych CIDOC CRM (v. 6.2.1), powstający pod patronatem The International Council of Museums (ICOM). Został on stworzony na potrzeby projektowania systemów zarządzania kolekcjami muzealnymi, lecz ze względu na swoją ogólność może też być stosowany praktycznie we wszelkiego rodzaju projektach informatycznych związanych z dziełami sztuki. Model ten jest zbudowany z takich typów danych jak: osoba, zdarzenie, rola, obiekt, pojęcie, miejsce. Określa on hierarchię ich podtypów, od pojęć najbardziej ogólnych do coraz bardziej szczegółowych, oraz definiuje relacje, jakie między nimi mogą istnieć.
Baza danych stworzona na potrzeby projektu „Obraz modyfikowany: recepcja grafiki w Królestwie Polskim od schyłku XV po początek XVII wieku. Przedmioty – osoby – środowiska – procesy” implementuje jedynie część modelu CIDOC niezbędną do opisania relacji pomiędzy dziełami sztuki w kontekście wpływów artystycznych, których są one świadectwem. Kluczowym przykładem takiej relacji może być związek twórcy (E21 Person – podtypu elementu E39 Actor) ze stworzonym przez niego dziełem. Rysunek, rycina, obraz lub inne dzieło sztuki są w tym modelu podtypami elementu E22 Man-Made Object (który w modelu CIDOC CRM jest ostatnim elementem w hierarchii: E1 CRM Entity → E92 Spacetime Volume → E18 Physical Thing → E24 Physical Man-Made Thing → E22 Man-Made Object). I choć mogłoby się wydawać, że powiązanie jedną relacją twórcy z wytworzonym przez niego dziełem jest oczywistością, to w modelu CIDOC CRM taka relacja nie jest zdefiniowana. Można ją zapisać jedynie niebezpośrednio, tzn. jako łańcuch relacji, w którego centrum znajduje się element E12 Production. Jest on jednym z elementów hierarchii podtypów elementu E2 Temporal Entity, a więc zdarzeniem. W modelu CIDOC zdarzenia są łącznikami, umożliwiającymi zapisanie większości informacji dotyczących dzieł sztuki i ich twórców. Właśnie to rozbijanie na drobniejsze składniki sytuacji, które w powierzchownym oglądzie łączą bezpośrednie relacje, umożliwia uniknięcie tworzenia systemów informatycznych, które w pewnym momencie mogłyby okazać się niezdatne do rozbudowy.
Model CIDOC CRM dokładnie definiuje elementy niezbędne do tworzenia systemów do zarządzania zbiorami dzieł sztuki, pozostawiając pozostałe konteksty dzieła sztuki zdefiniowane w sposób ogólny, wymagający doprecyzowania. Tak jest też w przypadku wpływów artystycznych, które mogły odgrywać rolę w powstawaniu dzieł sztuki. W modelu tym jest zdefiniowana relacja P7 was influenced by (influenced), która łączy elementy E7 Activity i E1 CRM Entity. Umożliwia to w praktyce zapisanie związku pomiędzy dowolną czynnością a dowolnym elementem modelu CIDOC CRM. Takie podejście umożliwia jedynie stwierdzenie faktu jakiegoś wpływu na bardzo ogólnym poziomie.
W trakcie spotkań zespołu przyjęto, że konieczne będzie bardziej szczegółowe wyodrębnienie składowych elementów sytuacji oddziaływania artystycznego dzieł sztuki. I choć mówimy zwykle o wpływie jednych dzieł sztuki na inne, w rzeczywistości chodzi o wpływ kompozycji lub pewnych motywów – w każdym razie pewnych widzialnych cech – jednego dzieła sztuki na decyzje i działania twórców, którzy tworzą kolejne dzieła. Dlatego do modelu danych został dodany nowy element „wywarcie wpływu”, będący podtypem E2 Temporal Entity. O ile stworzenie modelu wpływu unikatowych dzieł sztuki nie jest skomplikowane, to sprawa jest dużo bardziej złożona w przypadku dzieł seryjnych, zwłaszcza umożliwiających wielokrotne reprodukcje. Zwykle nie można połączyć zdarzenia wpływu z konkretną odbitką graficzną, skoro wszystkie odbitki z jednej matrycy (a ściślej: z jednego stanu) przedstawiają taki sam obraz. CIDOC CRM zawiera element E38 Image, który doskonale nadawał się do roli łącznika pomiędzy zdarzeniem wpływu a dziełem graficznym. Jest on definiowany jako „distribution of form, tone and colour that may be found on surfaces such as photos, paintings, prints and sculptures”. W rzeczywistości każdy obiekt materialny, taki jak odbitka graficzna czy obraz, posiada swój własny, niepowtarzalny tak zdefiniowany „Image”. Jednak na potrzeby projektu przyjęto, że wszystkie odbitki z tego samego stanu przedstawiają ten sam „Image”. Dzięki temu, przy pomocy elementu E38 Image, można zapisać w bazie fakt wpływu dzieła graficznego na inne dzieło, nie określając, która konkretnie odbitka mogła taki wpływ wywrzeć.
Innym rodzajem oddziaływania, jaki może zostać zapisany w bazie, jest wpływ wywierany przez zestawy dzieł graficznych: cykle ilustracji książkowych, ryciny pomyślane pierwotnie jako serie, ale także zbiory powstałe wtórnie lub wyodrębnione przez współczesnych badaczy (określane w bazie jako „wirtualne obiekty złożone”). Takie zestawy składają się również z elementów typu E38 Image.
Powstanie bazy znacząco ułatwiły doświadczenia zebrane w trakcie innych projektów, które korzystały z modelu Topic Maps: „Poezja na marginesie cywilizacji. Degradacja i odrodzenie twórczości poetyckiej w latach 1864-1894 (podstawa bibliograficzno-materiałowa)” (projekt badawczy realizowany pod kierunkiem prof. dr hab. Radosława Okulicz-Kozaryna w ramach grantu NPRH 11 H 11 013880 przez międzyuczelniany zespół, działający pod auspicjami Towarzystwa Literackiego im. Adama Mickiewicza – http://pnamc.ehum.psnc.pl/) oraz „Nowy Korbut. Adam Mickiewicz – bibliografia podmiotowa” (projekt badawczy realizowany przez Wydział Filologii Polskiej i Klasycznej UAM w ramach grantu NPRH 11H 11 008080 pod kierunkiem prof. dr hab. Zbigniewa Przychodniaka).
Zamiast budować tradycyjną aplikację bazodanową, co byłoby kosztownym i długotrwałym procesem, wykorzystano zdefiniowany model danych do wygenerowania aplikacji w programie typu 4GL, Topincs. Projektowanie aplikacji w tym programie polega na zmapowaniu zdefiniowanego wcześniej modelu danych do modelu wewnętrznego opartego na standardzie map topik (Topic Maps ISO 13250) i TMCL (Topic Maps Constraint Language ISO 19756), przy pomocy wizualnego edytora. W informatyce takie rozwiązanie nazywa się metamodelowaniem. Dzięki temu baza mogła zacząć działać już w dwa miesiące po rozpoczęciu projektu.
Piotr Kopszak