Biblioteka 2.0 on Facebook
Biblioteka 2.0 Strona Główna

Biblioteka 2.0
Forum społeczności czytelników i bibliotekarzy cyfrowych

FAQFAQ  SzukajSzukaj  UżytkownicyUżytkownicy  GrupyGrupy  StatystykiStatystyki
RejestracjaRejestracja  ZalogujZaloguj  AlbumAlbum  DownloadDownload

Poprzedni temat «» Następny temat
Wyszukiwanie pełnotekstowe w bibliotekach cyfrowych
Autor Wiadomość
A.Pulikowski

Dołączył: 30 Wrz 2009
Posty: 10
Poziom: 2
HP: 0/30
 0%
MP: 14/14
 100%
EXP: 0/8
 0%
Wysłany: 2009-10-01, 00:07   Wyszukiwanie pełnotekstowe w bibliotekach cyfrowych

Dobry wieczór,

To mój pierwszy post na forum, dlatego wypada się przedstawić. Nazywam się Arkadiusz Pulikowski i jestem pracownikiem Instytutu Bibliotekoznawstwa i Informacji Naukowej Uniwersytetu Śląskiego.
Mniej więcej rok temu zainteresował mnie problem wyszukiwania pełnotekstowego w zasobach polskich bibliotek cyfrowych. Problemy są dwa – kiepski OCR formatu DjVu i jego niewidoczność w wyszukiwarkach internetowych, z Google na czele. Śledziłem kilka wątków poświęconych temu zagadnieniu na tym i podobnym forum serwisu EBIB. Ponieważ nie pojawiło się do tej pory rozwiązanie skutecznie niwelujące oba powyższe problemy, postanowiłem poszukać go samodzielnie. W ubiegłym tygodniu przedstawiłem swoją propozycję na X Forum Informacji Naukowej i Technicznej w Zakopanem. Prezentację w formacie PDF zamieściłem, dzięki uprzejmości Anety Drabek, w Śląskiej Bibliotece Cyfrowej pod adresem: http://www.sbc.org.pl/dlibra/docmetadata?id=13873
Inspiracja mojego pomysłu pojawia się na slajdzie nr 17 na rysunku u dołu. W okienku „View the book” mamy do dyspozycji kilka formatów. Slajd 19 przedstawia dokładniej koncepcję. Plik DjVu jest otwierany w FineReaderze 9 i rozpoznawany, po czym zapisywany jest jako dwuwarstwowy PDF z bardzo dobrym OCRem. Oprócz tego można zapisać sam tekst w ramach HTML-owych. Dzięki takiemu rozwiązaniu można wszystkie dotychczas zapisane w formacie DjVu pliki wzbogacić o wersję PDF. Jak widać na wspomnianym slajdzie nie zajmuje on znacząco więcej miejsca niż plik DjVu. Plik PDF zostanie zaindeksowany przez wyszukiwarki. Do odczytu w przeglądarce użytkownik wybierze (wskazana sugestia obok nazwy formatu) DjVu, do zapisu lokalnego z możliwością wykorzystania warstwy tekstowej najlepszy będzie plik PDF. Operację dodawania odpowiednika w formacie PDF (i ewentualnie TXT) można zautomatyzować, np. korzystając z programu tworzącego makra z rejestrowanych kliknięć użytkownika. W ten sposób można uwidocznić wszystko to, co do tej pory zostało zapisane w formacie DjVu. Przy tworzeniu nowych dokumentów można tworzyć plik PDF z oryginalnych skanów. OCR trwa minimalnie dłużej, ale zyskujemy nieco na jakości. Różnica nie jest jednak wielka i można pozostać przy automatycznym generowaniu pliku PDF z DjVu.
Pomimo iż Google zaindeksuje pliki PDF i staną się one widoczne w wynikach pracy tej (i nie tylko) wyszukiwarki, warto byłoby podpiąć do serwisu FBC wyszukiwarkę wykorzystującą usługę Google Custom. Pozowliłoby to zawężać wyszukiwanie tylko do naszych bibliotek cyfrowych.
Opisaną wyżej procedurę należałoby najpierw przetestować w jednej z bibliotek cyfrowych, a następnie optymalny jej zapis udostępnić pozostałym bibliotekom.

Ciekaw jestem Państwa opinii oraz odpowiedzi na kluczowe pytanie - czy dLibra może zostać przystosowana do prezentacji dokumentu w kilku formatach?

Pozdrawiam,
Arkadiusz Pulikowski
 
     
relis 


Wiek: 53
Dołączył: 13 Lut 2007
Posty: 790
Skąd: Biblioteka Śląska
Poziom: 25
HP: 14/1490
 1%
MP: 711/711
 100%
EXP: 24/73
 32%
Wysłany: 2009-10-01, 01:42   

Witam na forum. Fajnie, że świat nauki w końcu się tym wszystkim zainteresował ;-) .
Powyższe rozwiązanie - prezentacji wieloformatowej - zostało już kiedyś wywołane. Chodziło wówczas o możliwość prezentacji nie- i edytowalnej wersji TXT dla ewentualnej korekty.
Odpowiedź ze strony programistów brzmiała (post M. Werli):
Cytat:
Planujemy wsparcie dla obsługi kilku formatów jednej publikacji (np. TIFF, DjVu, HTML?). Jak to będzie to będzie można się zastanowić nad równoczesną prezentacją tych postaci. Ale tutaj pewnie znowu konieczne będzie dedykowane wsparcie dla poszczególnych formatów - zwłaszcza jeżeli np. przewinięcie w dół jednego postaci miałoby powodować to samo w drugiej

Przymiarki do rozwiązania jak u kolegi sugerowała (a właściwie wskazała że się przygotowuje) Joanna Potęga z Polony w odpowiedzi na propozycję Czytelnika, narzekającego na niewygodny sposób prezentacji treści w tej BC i potrzebą dobrego OCR.
Kiedyś także namyślaliśmy się nad wiązaniem do identyfikatora publikacji w wersji DJVU - TIFFów (masterów) - oczywiście nie do prezentacji, lecz mechanizm ten sam.

Dlibrowcy coś tam kombinują, lecz póki co jednak wysiłki poszły w kierunku polepszenia OCR z DjVu i wyciągnięcia go do indeksowalnego pliku, co według kolegów działa. Oczywiście lokalnie.

Nie jestem pewien czy FineReader 9.0 jest w stanie przerabiać pliki DjVu na PDF. Wg tej informacji - nie i otwiera takie:
Cytat:
otwieranie plików graficznych np. bmp, jpg, jpeg, jpeg 2000, tif, tiff, dcx, pcx, png xps
, czyli raczej należałoby ręcznie generować pliki PDF ze skanów, także dla już opublikowanych w BC DjVu i dopinać je do identyfikatorów publikacji (jak już będzie taka możliwość).
Co do wykorzystania zewnętrznego indeksera dla FBC - to lepsze niż nic i chyba już coś takiego nawet jest dzięki kolegom z KPBC, chociaż prezentacja wyników jest klasyczna dla Google. Lista przeszukiwanych BC jest dłuższa niż to wynika ze strony głównej.
_________________
Given enough eyeballs, all bugs are shallow.
ESR
It is not necessary to change; survival is not mandatory. ;-)
Edward Deming

http://relis-blog.blogspot.com
 
 
     
anetadr 

Dołączyła: 13 Lut 2007
Posty: 161
Skąd: Biblioteka UŚ
Poziom: 11
HP: 0/272
 0%
MP: 130/130
 100%
EXP: 19/25
 76%
Wysłany: 2009-10-01, 08:04   

Remi!

Fine Reader 9 jest w stanie przerobić DJVU do PDF-a, co sprawdziłam osobiście :).

Aneta
 
     
Tomasz Kalota 
Tomasz Kalota


Wiek: 48
Dołączył: 13 Lut 2007
Posty: 322
Skąd: Wrocław
Poziom: 16
HP: 0/556
 0%
MP: 265/265
 100%
EXP: 30/39
 76%
Wysłany: 2009-10-01, 12:28   Re: Wyszukiwanie pełnotekstowe w bibliotekach cyfrowych

A.Pulikowski napisał/a:
Dobry wieczór,

To mój pierwszy post na forum, dlatego wypada się przedstawić. Nazywam się Arkadiusz Pulikowski i jestem pracownikiem Instytutu Bibliotekoznawstwa i Informacji Naukowej Uniwersytetu Śląskiego.(...)

Witaj, świetnie że tu zajrzałeś :-) .

A.Pulikowski napisał/a:
(...)Mniej więcej rok temu zainteresował mnie problem wyszukiwania pełnotekstowego w zasobach polskich bibliotek cyfrowych. Problemy są dwa – kiepski OCR formatu DjVu i jego niewidoczność w wyszukiwarkach internetowych, z Google na czele.
(...)

Problemów pewnie jest więcej, ale faktycznie z punktu widzenia ekonomii uwagi oraz widoczności polskich BC te dwa, o których wspomniałeś są najistotniejsze. W BCUWr doszliśmy do wniosku, że w przypadku publikacji zakwalifikowanych do modelu informacyjnego, czyli takiego w którym głównym celem jest udostępnianie treści a nie obrazków należny przyjąć inna metodykę produkcji publikacji - zorientowana na OCR. Tutaj - http://forum.biblioteka20.pl/viewtopic.php?t=360 w skrócie kiedyś to opisałem. DjVu robimy na samym końcu z wcześniej przygotowanych PDFów, ale zaczynam się zastanawiać czy w przypadku "małych publikacji" jest sens przerabiać je na DjVu, czy może lepiej zostać przy PDFach.

Oczywiście pojawia się problem co zrobić z publikacjami już udostępnionymi w BC. Jest ich już dosyć sporo w polskich BC i pojawia się standardowy dylemat - poprawiamy to co już jest czy produkujemy nowe publikacje. Ja się skłaniam w stronę produkcji nowych treści, a to co już jest może kiedyś uda się poprawić. Ten dylemat będzie chyba nam towarzyszył zawsze ;-) .

Przy okazji polecam dyskusję z forum EBIB - http://ebib.oss.wroc.pl/phpBB/viewtopic.php?t=3800 a zwłaszcza informacje podane przez Marka Kolasę, to dzięki niemu zaczęliśmy stosować PDF2DjVu. Tak na marginesie to czasopisma publikowane w MBC mogą służyć jako przykład profesjonalnego podejścia do jakości publikacji.
_________________
Myśl więziona w księdze jest hańbą dla księgi.

Tomasz Kalota | Digitalizacja.pl | eBooki.com.pl
 
 
     
A.Pulikowski

Dołączył: 30 Wrz 2009
Posty: 10
Poziom: 2
HP: 0/30
 0%
MP: 14/14
 100%
EXP: 0/8
 0%
Wysłany: 2009-10-01, 15:23   

Witam ponownie,

Dziękuję za obie odpowiedzi. Po kolei się do nich ustosunkuję.

Prezentacja wieloformatowa nie wymaga dodatkowych zabiegów, poza stworzeniem odsyłacza do odpowiedniego pliku. W przytoczonym wątku, na który odpowiadał pan Marcin Werla chodziło o coś więcej, co faktycznie nie było proste w realizacji.

Starania pani Joanny Potęgi z Polany przyniosły efekt, gdyż znalazłem w Polonie pliki udostępnione nie tylko w postaci obrazów, ale również PDF. Szkoda, że nie trafiłem na nie wcześniej. Przykład: http://www.polona.pl/dlib...irids=1&lang=pl
Przełączanie w menu po lewej do wersji PDF jest ledwo widoczne i można nawet tego nie zauważyć. Możliwe, że kiedy przyglądałem się Polonie nie zauważyłem wyboru formatu właśnie z tego powodu. Choć Polona ma nietypową dLibrę, to jednak widać, że można bez problemu umieścić odsyłacze do dwóch formatów. Dla Polony obecność PDF jest jednak znacznie ważniejsza niż dla innych bibliotek dLibrowych, ponieważ nie korzysta ona z formatu djvu ale z jpg, co zupełnie uniemożliwia dostęp do zawartości tekstowej.

Wątki dotyczące ulepszeń OCR w djvu są mi znane. Moim zdaniem nie warto tego robić. Szybszą metodą na dobry OCR jest dwuwarstwowy PDF, który daje użytkownikom dodatkową alternatywę i co bardzo ważne jest widziany przez wyszukiwarki.

Tak jak już napisała Aneta Drabek, FineReader w wersji 9 czyta bez problemu format DjVu. W prezentacji na slajdzie nr 9 OCR wykonałem tym programem właśnie na pliku DjVu (nie na oryginalnych skanach). Widać więc, że OCR na wcześniej przygotowanych plikach DjVu jest bardzo skuteczny. Porównywałem to później z OCRem z oryginalnych skanów i różnica jest bardzo mała. OCR na DjVu wykonany FineReaderem i zapisany w dwuwarstwowym PDF jest więc skutecznym sposobem na odzyskanie tekstu dla użytkowników.

Google Custom stworzony przez KPBC jest na pewno nieznany użytkownikom. Jego miejsce powinno być w serwisie FBC. W tej chwili indeksuje 1/4 zasobów. Gdyby w bibliotekach cyfrowych pojawiły się PDFy mielibyśmy wszystko. Być może format PDF ułatwiłby programistom z dLibry stworzenie dedykowanej wyszukiwarki. Na pewno łatwiej w nim odsyłać do strony z wyszukanym terminem.

Konwersja PDF na DjVu za pomocą konwertera jest również dobrym sposobem dojścia do tego samego celu. Trzeba zrobić porównanie obu metod pod względem uzyskiwanego efektu. Tak czy inaczej, w obu przypadkach użytkownik powinien mieć do wyboru jeden z dwóch formatów. Jednak jeśli chodzi o dotychczas wytworzone pliki DjVu, to odzyskiwanie ich tak jak to opisałem jest prostsze bo nie wymaga sięgania do oryginalnych skanów i może być wykonane automatycznie np. w godzinach nocnych. Jestem absolutnie za odzyskaniem dotychczas opublikowanych dokumentów w formacie DjVu. To jak podałem ok. 200 000 dokumentów. Są one tak samo ważne jak kolejne 200 000, które się ukaże.

Pozdrawiam,
Arkadiusz Pulikowski
 
     
jkp 
jkp

Dołączyła: 14 Lut 2007
Posty: 59
Poziom: 6
HP: 0/104
 0%
MP: 49/49
 100%
EXP: 8/14
 57%
Wysłany: 2009-10-01, 20:42   

Dobry wieczór:),
jako, że wywołana, poczułam się w obowiązku choć słowo (no może dwa...;-))
dLibrę mamy jak najbardziej typową :-) , tyle, że połączoną z Systemem Zbiorów Zdigitalizowanych skąd prezentowane są jpegi
co do publikacji z "tekstowymi" formatami - mamy pdf-y dwuwarstowe, txt-y (a niekiedy nawet się zdarza, że jedna publikacja ma aż trzy reprezentacje: jpeg, pdf i txt). W chwili obecnej w Polonie znajduje się niewiele ponad 3000 publikacji z wersją tekstową (na 7700 książek - więc nie jest źle, ale mogłoby być lepiej.... 100% chociażby... może kiedyś się zdarzy - pozostaję z nadzieją :lol: )
z pozdrowieniami
JPotega
_________________
Joanna Potega
 
     
jkp 
jkp

Dołączyła: 14 Lut 2007
Posty: 59
Poziom: 6
HP: 0/104
 0%
MP: 49/49
 100%
EXP: 8/14
 57%
Wysłany: 2009-10-01, 20:53   

To jeszcze jedno (no może dwa...;-) małe słówko po obejrzenia prezentacji Pana Arkadiusza:
- w cBN Polona jest możliwe przeszukiwanie pełnotekstowe
- w świetle wywołanego tematu, obok aspektów techniczno/technologicznych, istotnym elementem jest też kwestia korekty (poprawy) uzyskanych automatycznie plików tekstowych (stosujemy korektę, ale nie jesteśmy w stanie poprawić w 100 %). Zatem ilość czy jakość? (jeśli jakość - to jaka?100 czy 80%?) (na marginesie - Gallica puszcza "brudne" OCR-y całkowicie rezygnując z korekty)
z pozdr
jp
_________________
Joanna Potega
 
     
A.Pulikowski

Dołączył: 30 Wrz 2009
Posty: 10
Poziom: 2
HP: 0/30
 0%
MP: 14/14
 100%
EXP: 0/8
 0%
Wysłany: 2009-10-01, 21:34   

Po tym co Pani napisała tym bardziej żałuję, że wcześniej nie dostrzegłem możliwości jakie CBN zaoferowała użytkownikom. Nie pochwaliłem CBN na Forum, ale w tekście do mat. konf. to nadrobię. Co gorsze, jak słusznie Pani zauważyła, napisałem, że w CBN nie można wyszukiwać pełnotekstowo. Przepraszam za to. Prawie połowa zbiorów to bardzo dużo :-)
Pisząc o nietypowej dLibrze miałem na myśli interfejs - odmienny od większości bibliotek. Dla mnie jest ogólnie mniej czytelny. Takie mam subiektywne odczucie. To wrażenie tworzy głownie menu po lewej z małą czcionką i co gorsze - czarno na brązowym. Ciężko się tam pochwalić PDFami i innymi funkcjami. Może warto rozważyć jakieś zmiany, oczywiście jeśli moje odczucia pokrywają się z odczuciami innych użytkowników.
Wracając do meritum, CBN pokazała, że można z powodzeniem prezentować w dLibrze wiele formatów dla tego samego dokumentu. Może inne biblioteki powinny też to rozważyć, szczególnie w kontekście uwidocznienia niewidocznego. Zakładając, że konwerster pdf2djvu działa poprawnie, dla nowotworzonych dokumentów dogodniejsze wydaje się wyjście od PDF i zakończenie DjVu. Dla utworzonych dotychczas plików DjVu optymalne wydaje się przekonwertowanie do pdf korzystając z możliwości otwarcia DjVu w FineReaderze.
Jeśli zaś chodzi o korektę OCR, to na pewno można ją wprowadzić tylko dla niektórych dokumentów. W tej chwili mamy jednak większy problem - OCR w DjVu jest taki jak na jednym ze slajdów. Tutaj możemy bardzo wiele zyskać tworząc alternatywę w postaci dwuwarstwowego PDFa. Wiadomo, że efekt końcowy nie będzie idealny, ale nieporównywalnie lepszy niż to co obecnie jest przechowywane w tekstowej warstwie plików DjVu.
 
     
Tomasz Kalota 
Tomasz Kalota


Wiek: 48
Dołączył: 13 Lut 2007
Posty: 322
Skąd: Wrocław
Poziom: 16
HP: 0/556
 0%
MP: 265/265
 100%
EXP: 30/39
 76%
Wysłany: 2009-10-02, 00:18   

A.Pulikowski napisał/a:
(...)Jestem absolutnie za odzyskaniem dotychczas opublikowanych dokumentów w formacie DjVu. To jak podałem ok. 200 000 dokumentów. Są one tak samo ważne jak kolejne 200 000, które się ukaże. (...)

Oczywiście nie podlega to dyskusji, że dokumenty, które już są opublikowane są tak samo ważne jak te których jeszcze nie ma. Problem polega na tym, że mamy ograniczone możliwości przerobowe, a czytelnik woli mieć dostęp do informacji niedoskonalej niż nie mieć dostępu wcale. To jest właśnie ten dylemat, czy poświecić ograniczony czas na dopieszczanie już dostępnej informacji czy zająć się udostępnianiem kolejnej. Ponadto udostępnianie kolejnej informacji w sposób bardziej doskonały dostarcza nam kolejnych doświadczeń i może się okazać, że jak udostępnimy kolejnych 500 000 publikacji to dojdziemy do wniosku, że to co wcześniej poprawialiśmy można poprawić jeszcze bardziej.
_________________
Myśl więziona w księdze jest hańbą dla księgi.

Tomasz Kalota | Digitalizacja.pl | eBooki.com.pl
 
 
     
Tomasz Kalota 
Tomasz Kalota


Wiek: 48
Dołączył: 13 Lut 2007
Posty: 322
Skąd: Wrocław
Poziom: 16
HP: 0/556
 0%
MP: 265/265
 100%
EXP: 30/39
 76%
Wysłany: 2009-10-02, 00:31   

A.Pulikowski napisał/a:
(...)
Jeśli zaś chodzi o korektę OCR, to na pewno można ją wprowadzić tylko dla niektórych dokumentów. W tej chwili mamy jednak większy problem - OCR w DjVu jest taki jak na jednym ze slajdów. Tutaj możemy bardzo wiele zyskać tworząc alternatywę w postaci dwuwarstwowego PDFa. Wiadomo, że efekt końcowy nie będzie idealny, ale nieporównywalnie lepszy niż to co obecnie jest przechowywane w tekstowej warstwie plików DjVu.

W przypadku korekty OCR mam podobne odczucia jak w przypadku dylematu związanego z poprawianiem już opublikowanych dokumentów. Wyobraźmy sobie sytuację, w której mozolnie robimy korektę OCR, a np. za 5 lat pojawia się oprogramowanie, oparte np. na sztucznej inteligencji, które tę korektę zrobi automatycznie. W takiej sytuacji tracimy czas, który można poświęcić na dostarczanie nowych treści.

Zgadzam się z alternatywą w postaci dwuwarstwowego PDFa, choć nie jest to kwestia formatu tylko metody produkcji dobrego OCRu.
_________________
Myśl więziona w księdze jest hańbą dla księgi.

Tomasz Kalota | Digitalizacja.pl | eBooki.com.pl
 
 
     
relis 


Wiek: 53
Dołączył: 13 Lut 2007
Posty: 790
Skąd: Biblioteka Śląska
Poziom: 25
HP: 14/1490
 1%
MP: 711/711
 100%
EXP: 24/73
 32%
Wysłany: 2009-10-02, 01:14   

A.Pulikowski napisał/a:

Prezentacja wieloformatowa nie wymaga dodatkowych zabiegów, poza stworzeniem odsyłacza do odpowiedniego pliku.

Obawiam się, że to nie jest takie łatwe, bowiem jak widać temat był ruszany już jakiś czas temu. W dLibrze "jaka jest", istnieje możliwość dołożenia kolejnego formatu, jednakże ramach mechanizmu kolejnego "wydania" publikacji, a nie o to tu chodzi. W trakcie publikowania każda publikacja otrzymuje unikalny identyfikator, który przekłada się na unikalny URL. Publikacja dokonuje się za pomocą modułu Redaktor, w którym, prócz wartość DC, wskazuje się obiekt cyfrowy ("treść"), stanowiący w przypadku DjVu (najczęściej w formacie "rozbitym") tzw. plik sterujący, powiązany z następnymi plikami, zawierającymi poszczególne strony - lub cały plik PDF (.doc, txt). Publikowanie dokonuje się więc za pomocą kreatora, który w przypadku możliwości równoległej prezentacji pliku innego formatu, musiałby mieć możliwość jego wskazania albo późniejszego dopublikowania. Zaś aplikacja Czytelnik winna umieć wówczas to wyświetlić w postaci zestawu linków do różnych formatów. Strona publikacji w dLibrze nie jest komponowana ręcznie, lecz jest efektem jakiegoś szablonu, który musiałby być oczywiście przebudowany, lecz jednocześnie zintegrowany z "wejściem" treści od strony Redaktora.

A.Pulikowski napisał/a:
Choć Polona ma nietypową dLibrę, to jednak widać, że można bez problemu umieścić odsyłacze do dwóch formatów.

Interfejs prezentacyjny Polony to "wyjście" innego systemu (SZZ), który przechowuje pliki prezentacyjne. Nie wiadomo na ile umieszczanie dodatkowych odsyłaczy jest tam zautomatyzowane, ale jakoś być musi, bo trudno sobie wyobrazić, by jej redaktorzy coś dopisywali na piechotę. Dlatego frazę "bez problemu" wziąłbym w ostrożny nawias. ;-)

A.Pulikowski napisał/a:
Wątki dotyczące ulepszeń OCR w djvu są mi znane. Moim zdaniem nie warto tego robić. Szybszą metodą na dobry OCR jest dwuwarstwowy PDF, który daje użytkownikom dodatkową alternatywę i co bardzo ważne jest widziany przez wyszukiwarki.

Stosowanie DjVu jest powszechne ze względu na jego małość, a także bardzo elastyczny (przy b. wyrafinowanym kompresorze) dobór parametrów kompresji. Ciekawe jest to porównanie wielkości z prezentacji, bowiem PDF jak dotąd był dużo większy. Jestem ciekaw porównania plików z innych obiektów w obu formatach. A że warto dostarczać użytkownikom alternatyw to jak najbardziej.

A.Pulikowski napisał/a:
OCR na DjVu wykonany FineReaderem i zapisany w dwuwarstwowym PDF jest więc skutecznym sposobem na odzyskanie tekstu dla użytkowników.

Tu tez potrzebna byłaby jakaś automatyzacja, co w przypadku publikowania od nowa zapewne dałoby się łatwiej osiągnąć, niż w przypadku cyfrowej "retrokonwersji" publikacji (wymiany na lepszą). Rzecz do przemyślenia i wymyślenia.

A.Pulikowski napisał/a:
Jednak jeśli chodzi o dotychczas wytworzone pliki DjVu, to odzyskiwanie ich tak jak to opisałem jest prostsze bo nie wymaga sięgania do oryginalnych skanów i może być wykonane automatycznie np. w godzinach nocnych. Jestem absolutnie za odzyskaniem dotychczas opublikowanych dokumentów w formacie DjVu. To jak podałem ok. 200 000 dokumentów. Są one tak samo ważne jak kolejne 200 000, które się ukaże.

Sama konwersja DjVu->PDF zapewne dałaby się obsłużyć jakoś wsadowo. Ale ze wspomnianą "retrokonwersją" publikacji w dLibrze może być gorzej.
_________________
Given enough eyeballs, all bugs are shallow.
ESR
It is not necessary to change; survival is not mandatory. ;-)
Edward Deming

http://relis-blog.blogspot.com
 
 
     
sk 
sk

Dołączył: 19 Lut 2007
Posty: 292
Skąd: KPBC, Toruń
Poziom: 15
HP: 0/488
 0%
MP: 233/233
 100%
EXP: 35/35
 100%
Wysłany: 2009-10-02, 18:15   

relis napisał/a:
(...) Dlibrowcy coś tam kombinują, lecz póki co jednak wysiłki poszły w kierunku polepszenia OCR z DjVu i wyciągnięcia go do indeksowalnego pliku, co według kolegów działa. Oczywiście lokalnie.

Ekstrakcja warstwy tekstowej i podsuwanie linków botom w dlibrze działa. Niemniej skutki są i pozostaną mizerne bez względu na jakość OCR. Pomijając nawet to, że działa to bardzo powoli (boty są cierpliwe), to można wątpić, czy ktokolwiek zechce linkować do warstwy tekstowej; w wynikach wyszukiwania te strony nie mają więc wielkich szans. Zresztą, gdyby nawet znalazły się wysoko, kto chciałby czytać "goły", zanieczyszczony i źle sformatowany tekst? Ze względu na brudny OCR w KPBC zdecydowaliśmy się dodać mały javascript przekierowujący do strony zawierającej opis i link do wersji DjVu. Nie jestem pewny czy z tego powodu, czy jakiegoś innego, Google jednak w końcu eliminuje strony z warstwą tekstową z indeksu. Przykładem mogą być linki podane w dyskusji dotyczącej tej sprawy. Nie ma już ich w wynikach wyszukiwania.

Można więc powiedzieć, że eksperyment dał wynik negatywny i w zasadzie można by go już zakończyć.

Oczywiście rozważane w tym wątku umieszczanie obiektów w formacie PDF dałoby lepsze rezultaty. Niemniej trudno nie wspomnieć o ciemnych stronach tego pomysłu. Oznacza przynajmniej dwa razy większe wykorzystanie przestrzeni dyskowej, dwa razy większy backup, dwa razy większe indeksy..., słowem dużo większe obciążenie bibloteki cyfrowej. U nas takie podwojenie miałoby taki skutek, ze już teraz musielibyśmy myśleć o zakupie nowego serwera albo szybkiej macierzy. Niestety, również i pod tym względem daleko nam do Google, gdzie w razie potrzeby zawsze można zatrudnić dodatkową farmę serwerów :-) . O dodatkowej pracy nie wspomnę.

A.Pulikowski napisał/a:
Google Custom stworzony przez KPBC jest na pewno nieznany użytkownikom.

Owszem, w dwojakim znaczeniu. Użytkownicy nie znają tej wyszukiwarki i co więcej, nie chcą jej znać. Przez długi czas trzymaliśmy link na stronie głównej, pies z kulawą nogą z tego nie korzystał. Ta papuga jest więc martwa. Nie można wykluczyć, że ożyłaby, gdyby pozwalała na wyszukiwanie w pełnym tekście, a nie tylko w opisach, ale ręki nie dałbym sobie uciąć.
 
     
relis 


Wiek: 53
Dołączył: 13 Lut 2007
Posty: 790
Skąd: Biblioteka Śląska
Poziom: 25
HP: 14/1490
 1%
MP: 711/711
 100%
EXP: 24/73
 32%
Wysłany: 2009-10-03, 11:07   

sk napisał/a:

Ekstrakcja warstwy tekstowej i podsuwanie linków botom w dlibrze działa. Niemniej skutki są i pozostaną mizerne bez względu na jakość OCR. Pomijając nawet to, że działa to bardzo powoli (boty są cierpliwe), to można wątpić, czy ktokolwiek zechce linkować do warstwy tekstowej; w wynikach wyszukiwania te strony nie mają więc wielkich szans. Zresztą, gdyby nawet znalazły się wysoko, kto chciałby czytać "goły", zanieczyszczony i źle sformatowany tekst? Ze względu na brudny OCR w KPBC zdecydowaliśmy się dodać mały javascript przekierowujący do strony zawierającej opis i link do wersji DjVu. Nie jestem pewny czy z tego powodu, czy jakiegoś innego, Google jednak w końcu eliminuje strony z warstwą tekstową z indeksu.

A czy nie przypuszczasz, że było to właśnie związane z nędzna jakością OCR? Mimo, że Google to głownie syntaktyka, jednak fakt, że umie on rozpoznawać błędnie wpisany warunek wyszukiwawczy, proponując "czy chodziło ci o:", wskazuje, że najpewniej dzięki potężnym indeksom potrafi on rozpoznawać "odchylenia syntaktyczne" od wyliczonej "syntaktycznej średniej" dla danego języka. W konsekwencji, jeśli wynik indeksowania przynosi nagromadzenie syntaktycznego śmiecia (czyli efektu OCR z DjVu), jest on po prostu usuwany z wyników wyszukiwania, ponieważ mocno odstaje od tej średniej dla dowolnego języka.

sk napisał/a:
Oczywiście rozważane w tym wątku umieszczanie obiektów w formacie PDF dałoby lepsze rezultaty. Niemniej trudno nie wspomnieć o ciemnych stronach tego pomysłu. Oznacza przynajmniej dwa razy większe wykorzystanie przestrzeni dyskowej, dwa razy większy backup, dwa razy większe indeksy..., słowem dużo większe obciążenie bibloteki cyfrowej. U nas takie podwojenie miałoby taki skutek, ze już teraz musielibyśmy myśleć o zakupie nowego serwera albo szybkiej macierzy.

Niemniej sam pomysł umożliwienia podczepiania dodatkowych formatów pod identyfikator publikacji jest sensowny. Kto będzie mógł, podczepi, inni zrobią to później. Warunki sprzętowe w końcu się poprawią, a nie wszystko także trzeba zaopatrywać w dodatkowe wersje. Taki sam dylemat omawialiśmy już, gdy zastanawialiśmy się w jakich publikacjach poprawiać OCR, a jakie zostawić do poprawy przyszłym pokoleniom. :-)

sk napisał/a:
A.Pulikowski napisał/a:
Google Custom stworzony przez KPBC jest na pewno nieznany użytkownikom.

Owszem, w dwojakim znaczeniu. Użytkownicy nie znają tej wyszukiwarki i co więcej, nie chcą jej znać. Przez długi czas trzymaliśmy link na stronie głównej, pies z kulawą nogą z tego nie korzystał. Ta papuga jest więc martwa. Nie można wykluczyć, że ożyłaby, gdyby pozwalała na wyszukiwanie w pełnym tekście, a nie tylko w opisach, ale ręki nie dałbym sobie uciąć.

Nie znam dokładnie Custom i nie wiem jak bardzo można by go "skastomizować" dla systemu. Lista odpowiedzi jest formatowane algorytmem Google, zgodnie z zasadami o których wiedzą lub domyślają się pozycjonerzy. Pozycje wylistowane ze wzgl. na metadane są wymieszane z frazami w pełnych tekstach, etc. Jeśli oczekiwalibyśmy lepszej jakość odpowiedzi z możliwością zawężania zapytań wg DC lub wskazania wyłącznie treści, należałoby skoncentrować się bardziej na zrobieniu z FBC solidnej wyszukiwarki o możliwościach wyszukiwania jak w poszczególnych BC.
_________________
Given enough eyeballs, all bugs are shallow.
ESR
It is not necessary to change; survival is not mandatory. ;-)
Edward Deming

http://relis-blog.blogspot.com
 
 
     
A.Pulikowski

Dołączył: 30 Wrz 2009
Posty: 10
Poziom: 2
HP: 0/30
 0%
MP: 14/14
 100%
EXP: 0/8
 0%
Wysłany: 2009-10-03, 11:40   

W DjVu na dobry OCR nie ma co liczyć. Oprogramowanie firmowe poza czytnikami rozwija się ślamazarnie. Nie oczekiwałbym na pojawienie się np. silnika FineReadera w Document Expressie. Prędzej doczekamy się PDFa z rozbitymi na pliki stronami. PDF dla większości użytkowników jest znanym formatem. Udostępnienie tego formatu oprócz DjVu może być więc dodatkowo korzystne z punktu widzenia użytkowników przyzwyczajonych do Adobe Acrobat Readera.

Obserwując liczbę zmian wprowadzanych w kolejnych wydaniach dLibry, nie wydaje mi się by wprowadzenie do kreatora redaktora i interfejsu użytkownika możliwości obsługi alternatywnych formatów do wyboru użytkownika była dużym problemem. W tej kwestii muszą się oczywiście wypowiedzieć programiści dLibry. Biorąc jednak pod uwagę korzyści jakie przyniosłoby wprowadzenie tych zmian, uważam, że nawet gdyby było to czasochłonne zadanie jest warte podjęcia. Może nie jest to takie „bezproblemowe” jak wcześniej napisałem, ale na pewno znacznie mniej niż np. wprowadzenie tagowania.

Jak tylko znajdę trochę czasu to przygotuję porównanie rozmiaru wynikowych PDFów dla większej liczby i bardziej różnorodnych dokumentów. Nie wiem czy nie ma tu znaczenie to, że w moim teście na wejściu był djvu a nie pojedyncze skany. To jeszcze dziś porównam i przekażę wyniki.

Jeśli chodzi o automatyzację procesów tworzenia nowych dokumentów w obu formatach i poprawiania wcześniej opublikowanych to trzeba to empirycznie przetestować. W przyszłym tygodniu postaram się takie próby podjąć. O wynikach oczywiście napiszę tutaj. Oczywiście nie mając możliwości finalizowania procesu w dLibrze nie będą to procedury pełne, ale być może takie testy pomogą wskazać programistom dLibry co można zrobić by automatyzacja tych procesów była optymalna.

Jeśli chodzi o zwiększenie obciążeń bibliotek cyfrowych związanego z wprowadzeniem alternatywnych PDFów to nie będzie tak źle. Przyrost nie będzie gwałtowny. Uzupełnianie wcześniejszych publikacji o PDFy wymaga czasu. Nowe dokumenty będą pożerać więcej miejsca, ale nie od razu zjedzą wszystko. Nie wiadomo nawet ile będzie trzeba poczekać na pojawienie się w dLibrze niezbędnych zmian umożliwiających podpinanie dodatkowych formatów. Skoro proces będzie rozłożony w czasie to korzystać będziemy równocześnie ze zwiększających się cały czas pojemności dysków, szybkości procesorów itp. Biblioteki, które dysponują lepszym sprzętem mogą szybciej retroOCRować :-) inne wolniej.

Problem zachęcenia użytkowników do wyszukiwania pełnotekstowego wymaga przemyślenia. Jednak nikt chyba nie zaprzeczy, że użytkownicy oczekują narzędzia, które umożliwi im wyszukiwanie pełnotekstowe i zrealizuje to w sposób wygodny. Google Custom to tylko tania opcja do czasu dorobienia się lepszej – własnej.

Zauważyłem właśnie post R.Lisa. Patrząc na to co sam wyżej napisałem widzę zbieżność w kilku sprawach, z czego bardzo się cieszę.
 
     
relis 


Wiek: 53
Dołączył: 13 Lut 2007
Posty: 790
Skąd: Biblioteka Śląska
Poziom: 25
HP: 14/1490
 1%
MP: 711/711
 100%
EXP: 24/73
 32%
Wysłany: 2009-10-03, 21:08   

A.Pulikowski napisał/a:

Jak tylko znajdę trochę czasu to przygotuję porównanie rozmiaru wynikowych PDFów dla większej liczby i bardziej różnorodnych dokumentów. Nie wiem czy nie ma tu znaczenie to, że w moim teście na wejściu był djvu a nie pojedyncze skany. To jeszcze dziś porównam i przekażę wyniki.

Jeśli chodzi o automatyzację procesów tworzenia nowych dokumentów w obu formatach i poprawiania wcześniej opublikowanych to trzeba to empirycznie przetestować. W przyszłym tygodniu postaram się takie próby podjąć. O wynikach oczywiście napiszę tutaj. Oczywiście nie mając możliwości finalizowania procesu w dLibrze nie będą to procedury pełne, ale być może takie testy pomogą wskazać programistom dLibry co można zrobić by automatyzacja tych procesów była optymalna.

Gdyby kolega chciał potestować powyższe rzeczy, a cierpiał na brak dostępu do narzędzi oraz do dLibry, zapraszam do naszej SPD. Adobe Acrobat, Fine Reader Corporate, DjVu Document Expres, DjVu Enterprise Server, Redaktor dLibry + dwóch bibliotekarsko-informatycznych magików ze skłonnościami do eksperymentów. Odległość od IBIN - jakieś 600 m. ;-)
_________________
Given enough eyeballs, all bugs are shallow.
ESR
It is not necessary to change; survival is not mandatory. ;-)
Edward Deming

http://relis-blog.blogspot.com
 
 
     
Wyświetl posty z ostatnich:   
Ten temat jest zablokowany bez możliwości zmiany postów lub pisania odpowiedzi
Nie możesz pisać nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz głosować w ankietach
Nie możesz załączać plików na tym forum
Możesz ściągać załączniki na tym forum
Dodaj temat do Ulubionych
Wersja do druku

Skocz do:  

Powered by phpBB modified by Przemo © 2003 phpBB Group
Biblioteka 2.0 : Forum społeczności czytelników i bibliotekarzy cyfrowych [Dokument elektroniczny] - Tryb dostępu http://forum.biblioteka20.pl
Korzystanie z portalu oznacza akceptację naszej polityki prywatności.
Strona wygenerowana w 0.1 sekundy. Zapytań do SQL: 8