ORGANIZACJA WIEDZY W BIBLIOTEKACH
6.3. Ontologią sieciowych dokumentów elektronicznych
6.3.6. Problemy aplikacyjne ontologii
Przyjęcie modelu trójpoziomowego z priorytetem przyznanym jednostce Obiekt prowadzidonastępującychwniosków, dotyczących jego implementacji:
• Wystąpienie jednostki, której przyznano prymat, należy tworzyć dla każdego opi
sywanego dokumentu.
• Podstawą tworzenia rekordów bibliograficznych musi być jednostka nadrzędna, a więcjednostka poziomu Realizacji, a niepoziomuMaterializacji.
• Główne atrybuty, takie jak ‘Tytuły’, ‘Twórcy’, a także inne atrybuty występujące w dokumencie (pomijając pewne wyjątki), muszą być związane z jednostką nad rzędną. Inne atrybuty (a także elementy danych), dodatkowo charakteryzujące tę jednostkę, także muszą być znią związane.
• Ważne relacje pomiędzy wystąpieniamijednostki nadrzędnej muszą być identyfi
kowane i reprezentowane w każdym przypadku.
• Na podstawiedwóch poprzednichpunktów należystwierdzić, że zadania użytkow nika związane z jednostką nadrzędnąsą realizowane za pomocą atrybutów związa nych ztąjednostkąi relacjami pomiędzy wystąpieniami jednostki.
• Proces wyszukiwania prowadzonyprzez użytkownikówrozpoczyna się od realiza
cji zadania związanego z jednostką nadrzędną (np. ‘znaleźć’jednostkę tego pozio
mu). Wystąpienia tej jednostki także są ‘identyfikowane’ lub ‘wybrane’ w trakcie tego procesu [Taniguchi2003a].
Pomimo że celem pracy nie jest tworzenie katalogu dokumentów dostępnych w Webie, można przedstawić kilka postulatów dotyczących implementacji ontologii.
Biorąc pod uwagę możliwości zastosowania różnych metod tworzenia rekordów bi
bliograficznych z punktu widzenia modelupriorytetu jednostki Obiekt oraz strukturę konceptualną,możnawyodrębnić dwie grupymetod budowyrekordów: polegającą na tworzeniu pojedynczego rekordu bibliograficznego lub wielu rekordów powiązanych hierarchicznie. W pierwszym wypadku rekordy powstają zarówno na poziomie Obiektu, jak i na poziomieDzieła, przy czym wszystkie elementydanychodpowiada
jąceNośnikowiumieszczane sąna poziomie Obiektu. W efekcienie powstają odrębne rekordy dla różnych Nośników jednego Obiektu. Podejście polegające na budowaniu
156 Opis dokumentów elektronicznych. Teoretyczny model i możliwości jego aplikacji
hierarchii rekordów służy tworzeniu rekordów na dwóch poziomach - zarówno Obiektu,jak i Nośnika, oprócz poziomu Dzieła. W obu przypadkachrekordy poziomu Dzieła odpowiadająrekordomautorytatywnym tytułów ujednoliconych.
Weźmypod uwagę stronę domową, złożoną z określonej liczby stron, które zkolei składają się z jednegolubkilku plików (np. jakaś strona Webmoże byćplikiem PDF, a inna składać się z pliku HTML, kilku obrazków GIF i animacji Flash). Po pierwsze, możemyjeden plik wyznaczyćjako nadrzędny, a inne opisać jako uporządkowane lub nieuporządkowane pliki podrzędne, powielając informację o ich powiązaniach zapisa
ną wewnątrzplików,jako metadane. Po drugie, strona domowa- jako całość utworzo na z wielu plików -może być opisana jako jeden Obiektskładający się zwielu części (rys. 28, część lewa).
Alternatywą jestopisywanie każdej zagregowanej strony Web odrębnie i wiązanie ich zesobą relacjączęść-całość (rys. 28, część prawa). Zauważmy,że każdy element strony powiązanyjest relacją Jest częścią” ze swoją stroną. Jeden z elementów - plik typuGIF, połączony jestzewszystkimi stronami. Każdy z tych sposobów modelowa
nia wymaga jednak określenia jednego pliku jako nadrzędnego, czyli takiego, od któ
regorozpoczyna się powtórne scalanie plikóww stronę WWW. Metoda polegającana tworzeniu pojedynczego rekordu została opisana w raporcie JSC AACR jako katalo
gowanie na poziomieRealizacji [Bowen 2001]. Zaproponowano kilka wariantów sto
sowania tego sposobu, np. przy użyciu rekordów zasobu. W tym wypadku główną korzyścią jest uniknięciepotrzeby tworzenia pełnego rekordukatalogowegodla każde
goNośnika, copozwalana oszczędność czasu i pieniędzy. Innązaletą jest możliwość takiego wyświetlania danych,abyużytkownicy mogli obejrzeć wszystkie Materializa
cje w jednym rekordzie.
Podejście to ma także pewne wady. Powodująone potrzebę rozwiązania następują cych problemów:
• Niezbędne jest utworzenie kryteriów identyfikacji jednostki Obiekt, gdyż rekordy mają być tworzone w oparciu o tęjednostkę.Kryteria takie powinny odwoływać się do zasadidentyfikacji jednostki.Muszą one być praktycznei łatwe do wdrożenia.
• Zagadnienie liczności relacji pomiędzy Obiektem i Nośnikiem. Liczność relacji między tymi jednostkami określona jest jako „wiele do wielu”, co powoduje, że, np.
należy określić sposób postępowania w przypadkach, gdy pojedynczy Nośnik za wiera więcej niż jeden Obiekt.
Rys.28.RelacjemiędzyskładnikamiwobrębieObiektu',dwieopcje[Caplan2005]
158 Opis dokumentów elektronicznych. Teoretyczny model i możliwości jego aplikacji
• W celu stworzenia ogólnego opisujednostki Obiekt, który obejmowałbywszystkie Nośniki tego Obiektu, należałoby mieć dostęp do wszystkich jego Reprezentacji.
Powodujeto potrzebę zmiany przepisów katalogowania w kierunku uwzględnienia kolejno pojawiających się Nośników.
• W przypadku dokumentów digitalizowanych, gdy biblioteka posiada obie (trady cyjną i cyfrową) Realizacje Dzieła, należy spodziewać się problemów z wymianą i rozpowszechnianiem rekordów. Biblioteki zazwyczaj nie dysponują wszystkimi Materializacjami danej Realizacji. W pewnych przypadkach mogą występować trudności z automatycznym łączeniem rekordów, zawierających wartości elementu danych reprezentujące tylko niektóre Materializacje pewnej Realizacji.
• Jeżeli automatyczna konwersja istniejących rekordów nie powiedzie się, może na stąpićrozdźwiękmiędzyistniejącymi a nowymi rekordami.
Na rysunku 29 przedstawiono sposób postępowania podczas tworzenia jednostek modelu. Uwzględniono dwiesytuacje: opis dokumentu tradycyjnego przekształconego w stronę Web oraz opis dokumentu elektronicznego tworzonego wyłącznie w celu udostępniania w sieci. Poszczególnym jednostkom modelu przypisane zostały ich atry buty. Są to atrybuty dokumentu elektronicznego wyróżnione w schemaciemetadanych Dublin Core (DCMES), gdzie spełniająrolę elementów metadanych. Tam, gdzie było topotrzebne,zastosowano elementy kwalifikowane.
Poniżej przedstawiono przykład opisów wybranych stron Web według schematu przedstawionego na rysunku 29. Jakjuż wskazywano, opisy te nie stanowiąkomplet nych rekordów bibliograficznych, gdyż ich zadaniem jest jedynie egzemplifikacja za
stosowania zaproponowanej ontologii, bazującej na modelu trójpoziomowym. Dla stworzenia pełnych opisów niezbędne byłoby przyjęcie istniejących lub stworzenie własnych przepisów opracowania zbiorów, uwzględniających podane wcześniej wnio
ski. Pozostaje to jednak poza zakresemniniejszej pracy.
Przykład: Stronadomowa Marka Nahotko.
W przykładzie przedstawiono opis strony domowej. Jest ona stroną domowąautora tej książki. Ze względu na oszczędność miejsca nie zamieszczono opisów wszystkich Obiektów i elementów, które tam się znajdują, wybranotylko jeden plik HTML, będą cy głównym elementem strony domowej, kilka plików HTML stanowiących strony Web (agregaty) i jedenobraz JPG(składnik strony).
Obiektyzagregowane połączone są odpowiednimi relacjami, wskazującymi ich hie rarchię (relacja „Złożonyz” i „Jest częścią”). Dublin Core pozwala także na wykazanie innego typu relacji, np. wskazujących na istnienie odnośników pomiędzy stronami.
Właściwośćtatakżezostałaprzedstawiona w przykładzie (relacja „Cytuje”).
WszystkieZapisyniezbędne do stworzeniaReprezentacji Obiektu połączone są hie rarchicznymi relacjami z Obiektem uznanym za nadrzędny w stosunku do innych. Za pisytestanowią składnikistrony Web.
Dokument tradycyjny Rys.29.Sposóbpostępowaniapodczastworzeniametadanych:jednostkiiichatrybuty(oprać,własne)
160 Opis dokumentów elektronicznych. Teoretyczny model i możliwości jego aplikacji
Obiekt1:stronadomowa
Jednostka Atrybut Atrybut
(kwalifikacja) Wartość
Wydarzenie 1 (Tworzenie)
Data 2001-05-12
Miejsce Kraków
Agent Twórca Nahotko, Marek
Współtwórca
Dzieło Tytuł Moja stronadomowa
Źródło Relacja Wydarzenie 2
(Wyrażanie)
Data Utworzenia 2001-06-10
Data Modyfikacji
Data Copyright
Miejsce Kraków
Agent Twórca Nahotko, Marek
Współtwórca Własność
Obiekt Identyfikator http://nahotko.webpark.pl
Tytuł Mojastrona domowa
Tytuł Wariant
Format HTML
Typ collection
Język poi
Relacja Złożony z http://nahotko.webpark.pl/lista.htm Relacja Złożony z http://nahotko.webpark.pl/autoreferat.htm Relacja Złożony z http://mamah.webpark.pl/dwory.html Wydarzenie 3
(Ucieleśnienie)
Data Wydania 2001-07-01
Data Dostępu
Agent Wydawca Nahotko,Marek
Nośnik Wymagania
systemowe
Tytuł Moja strona domowa
Tytuł Wariant
Zapis Identyfikator http://nahotko.webpark.pl/index.html
URI
Dane pliku HTML, 7171 b
Oznaczenie wersji
Zapis Identyfikator http://nahotko.webpark.pl/zdjecie.jpg
URI
Dane pliku JPG,3477 b
Oznaczenie wersji Reprezentacja Ograniczenia do
stępu
Modelowanie sieciowych dokumentów elektronicznych 161
Obiekt 2: stronaWeb,podstrona strony domowej
Jednostka Atrybut Atrybut
(kwalifikacja) Wartość
Wydarzenie 1 (Tworzenie)
Data 2002-03-23
Miejsce Kraków
Agent Twórca Nahotko, Marek
Współtwórca
Dzieło Tytuł Dwory i dworki
Źródło Relacja Wydarzenie 2
(Wyrażanie)
Data Utworzenia 2002-03-25
Data Modyfikacji
Data Copyright
Miejsce Kraków
Agent Twórca Nahotko, Marek
Współtwórca Własność
Obiekt Identyfikator http://mamah.webpark.pl/
Tytuł Dwory i dworki
Tytuł Wariant
Format HTML
Typ collection
Język poi
Relacja Złożony z http://mamah.webpark.pl/linki.html Relacja Jestczęścią http://nahotko.webpark.pl/
Relacja Cytuje http://portalwiedzy.onet.p1/41799,haslo.html Wydarzenie 3
(Ucieleśnienie)
Data Wydania 2003-03-25
Data Dostępu
Agent Wydawca Nahotko, Marek
Nośnik Wymagania
systemowe
Tytuł Dwory i dworki
Tytuł Wariant
Zapis Identyfikator http://mamah.webpark.pl/dwory.html
URI
Dane pliku HTML,18416 b
Oznaczenie wersji
Zapis Identyfikator http://mamah.webpark.pl/dwor.jpg
URI
Dane pliku JPG, 23052 b
Oznaczenie wersji Reprezentacja Ograniczenia
dostępu
162 Opis dokumentów elektronicznych. Teoretyczny model i możliwości jego aplikacji
Obiekt 3: obraz zestrony Web
Jednostka Atrybut Atrybut (kwalifikacja) Wartość Wydarzenie 1
(Tworzenie)
Data 1998-05-12
Miejsce Kraków
Agent Twórca
Współtwórca
Dzieło Tytuł Marek Nahotko
Źródło Relacja Wydarzenie 2
(Wyrażanie)
Data Utworzenia 1998-05-12
Data Modyfikacji
Data Copyright
Miejsce Kraków
Agent Twórca
Współtwórca Własność
Obiekt Identyfikator http://nahotko.webpark.pl/zdjecie.jpg
Tytuł Marek Nahotko
Tytuł Wariant
Format JPG
Typ image
Język
Relacja Jest częścią http://nahotko.webpark.pl/
Wydarzenie3 (Ucieleśnienie)
Data Wydania 2001-07-01
Data Dostępu
Agent Wydawca Nahotko, Marek
Nośnik Wymagania
systemowe
Tytuł Marek Nahotko
Tytuł Wariant
Zapis Identyfikator http://nahotko.webpark.pl/zdjecie.jpg
Dane pliku JPG
Oznaczenie wersji Reprezentacja Ograniczenia
dostępu
Modelowanie sieciowych dokumentów elektronicznych 163
Obiekt 4:strona Web, podstronastrony domowej
Jednostka Atrybut Atrybut (kwa
lifikacja) Wartość
Wydarzenie 1 (Tworzenie)
Data 2003-05-30
Miejsce Kraków
Agent Twórca Nahotko, Marek
Współtwórca
Dzieło Tytuł Autoreferat
Źródło Relacja Wydarzenie 2
(Wyrażanie)
Data Utworzenia 2003-05-30
Data Modyfikacji
Data Copyright
Miejsce Kraków
Agent Twórca Nahotko, Marek
Współtwórca Własność
Obiekt Identyfikator http://nahotko.webpark.pl/autoreferat.htm
Tytuł Autoreferat
Tytuł Wariant
Format HTML, PPT
Typ collection
Język poi
Relacja Jest częścią http://nahotko.webpark.pl/
Wydarzenie 3 (Ucieleśnienie)
Data Wydania 2003-05-30
Data Dostępu 2003-05-30
Agent Wydawca Nahotko,Marek
Nośnik Wymagania syste mowe
Tytuł Autoreferat
Tytuł Wariant
Zapis Identyfikator http://nahotko.webpark.pl/Autoreferat_pliki /frame.htm
Dane pliku HTML, prezentacja PowerPoint 8391b Oznaczeniewersji
Zapis Identyfikator http://nahotko.webpark.pl/Autoreferat_pliki /slide0002.htm
Dane pliku HTML, prezentacja PowerPoint 10841 b Oznaczeniewersji
Reprezentacja Ograniczenia dostępu
164 Opis dokumentów elektronicznych. Teoretyczny model i możliwości jego aplikacji
Podczas implementacji ontologii konieczne będzie rozwiązanie problemów doty
czących sposobu prezentacji danych, czyli interfejsuużytkownika. Marie-Louise Ayres przedstawiła następujące propozycje funkcjonowania interfejsu pozwalającego na przedstawienie relacji pomiędzyDziełami, Realizacjami i Materializacjami'.
• Wielokrotne Realizacje poprzedzane są prostym komunikatem: „To dzieło wystę puje w x różnych wersjach”.
• Numerowanie kolejnych Realizacji, szeregowanych według daty pierwszej Mate rializacji należącej dokażdej Realizacji.
• Włączenie informacji specyficznej dla Realizacji, takiej jak wersja tytułu lub tłu macz.
• Wielorakie Materializacje poprzedzone są prostym komunikatem: „Ta wersja dzieła publikowana była xrazy”.
• Włączenie informacji specyficznej dla Materializacji (takiej jak wydawca, miejsce i data wydania) [Ayresiin. 2002].
Wydaje się, że realizacja tych zasad na etapie wdrożeniowymmoże ułatwićpercep
cję przedstawionych jednostek bibliograficznych dzięki prostemu obrazowaniu relacji funkcjonujących między nimi.