Каталог электронной библиотеки

[vitus_wagner]

В связи с тем, что lib.rus.ec окончательно скурвился я купил себе 32Гб SD-шку, возникает вопрос о работе с НУ ОЧЕНЬ большим набором электроных книг.

И да, primary target platform - maemo.

Т.е. возникает задача хранения каталога библиотеки отдельно от самой библиотеки, периодической актуализации и т.д.

Основная операция с этим каталогом - найти некоторое множество книг и вытащить его в "рабочий набор", то есть в случае maemo в рабочий каталог FBReader-а, владельцы всяких lbook-ов и openinkpot-ов лучше знают, что у них там.

phd тут рекламировал MyRuLib. Мне не понравилось. Во-первых, оно требует свежего wxWidgets. Более свежего чем в lenny (хотя пакет якобы для Debian 5.0 на сайте есть), так что даже на десктопе попробовать не получилось.
Во-вторых, в maemo вообще с wxWidgets туго.

В третьих, залез я в их базу данных посредством sqlite и показалось мне что проектировал её типичный php-кодер. Поле genres в таблице books, содержащее конкатенацию каких-то кодов...

Вот и думаю теперь что делать. Либо пытаться все же использовать эту заботливо подготовленную неграмотными людьми базу, либо писать свою извлекалку метаинформации из fb2 (pdf и djvu меня интересуют меньше, потому что на 32Гб флэшку они не влезут и читать их на экране 800x480 неудобно).

Либо вообще прикрутить sqlite-каталог к FBReader-у.

Но вот как должен выглядеть интерфейс этого библиотечного приложения?
Очевидно что просмотр списка из десятков тысяч авторов - не вариант. Тем более что нужен поиск по сериалам (sequence) или названиям.

Столь же очевидно, что о полнотекстовом поиске сразу надо забыть. Сделать полнотекстовый индекс существенно меньший по объему, чем сама библиотека вряд ли удастся, а библиотека занимает более половины доступного объема.

Ничего лучшего, чем повторить форму поиска на сайте lib.rus.ec мне в голову пока не приходит

Comments

[dzz.livejournal.com]

У букридеров работа с большими каталогами - вообще больное место (возникает вопрос - а зачем там тогда поддержка больших флэшек?).

По поводу интерфейса - с очевидностью, нужна рубрикация и поиск по автору, названию, жанру.

[vitus_wagner]

Откуда возьмется рубрикация? Мне бы на самом деле очень не помешал поиск по дате написания. Но, к сожалению, в большинстве книг из собрания rusec эта информация не проставлена.

почитал комменты на либрусеке

[cmotrujj.livejournal.com]

Странная сумма - 10 уе\месяц. Многовато. Вот 5 в год - еще куда-то как-то.
Похоже на проворкацию, вброс. Не торопиться с выводами, имхо.

Re: почитал комменты на либрусеке

[vitus_wagner]

GPRS все равно дороже. А главное - дороже время на выкачивание книги, когда она понадобилась. Поэтому иметь локальную копию библиотеки, синхронизируемую раз в несколько месяцев, все равно удобно, даже если бы lib.rus.ec оставлася бесплатным и работал бы без тормозов.

[dottedmag.livejournal.com]

Главное - чтобы D-Bus-интерфейс был!

Шучу, шучу.

[vitus_wagner]

Увы, доля шутки в твоей шутке не слишком велика. MyLibRu была отвергнута в основном потому, что используемый ей тулкит не умеет dbus интерфейса к таким важным фишкам hildon как виртуальная клавиатура и connection manager.

[http://users.livejournal.com/mak_/]

посмотрите на торрентс.ру библиотеку траума. у меня под рукой нет, но помнится туда включена база данных для желающих самостоятельно что-то структуризовать.

[vitus_wagner]

Смотрел я на нее. Как-то не проникся ее индексом.

[tritopora.livejournal.com]

О как, Ларин в душу наплевал, значит? Даже не знал. Конвертишь тут, вычитываешь, человечество благодетельствуешь в личное время, а тут такую плюху вываливают.

[fr0ster.livejournal.com]

Я только что зашел и скачал для пробы Лукьяненка. Думаю зарегится для скачки не такая и проблема.

Могу предложить Пургуру (с)

[neo-der-tall.livejournal.com]

Мы придумали такое http://www.e-uch.ru/ - справа "Библос" юзер и пароль guest

дисклэймер!

[neo-der-tall.livejournal.com]

а) это даже не прототип еще толком
б) проект заморожен
в) разрабатывалось под "тыканье пальцем"

[roman_sharp.livejournal.com]

У меня виндовая http://home-lib.net/ стоит. Особо яростно не гонял, но чего-то делала и выдавала. Может ссылка сгодиться на что...

[phd_ru]

Правильно. Не нужен Витусу на Maemo никакой wx. Нужен Wine! :-D

[alexkuklin.livejournal.com]

lib.rus.ec отступил на очередные заранее заготовленные позиции, как я понял

[vitus_wagner]

У тебя браузер перечеркнутый текст не отображает?

[permea-kra.livejournal.com]

Емнип, fb2-xml-based? распаковать - натравить xqilla с правильным запросом, проверить корректность завершения, запустить вывод xqilla на вход шелла, нет?

Полнотекстовый индекс нужен по полям с метаинформацией, полнотекстовый по книге практически бесполезен.

[vitus_wagner]

Либ.rus.ec это нынче под 200 тысяч книг. Поэтому напрямую искать по файлам на наладоннике - нереально.
Я пробовал работать таким образом с архивами альдебарана (которые на порядок меньше) и на десктопе, Пришел к выводу, что без БД тут никак.

[amarao-san.livejournal.com]

Ну, самые простые вещи, которые бы хотелось видеть - это sondex или что-то подобное для приблизительного поиска (перепутал букву в названии и т.д.) и всё-таки полнотекстовый поиск. Да, делать полный индекс тяжко (кстати, не факт, что он такой уж большой будет - слов в языке много меньше, чем текстов с этими словами).

[vitus_wagner]

Кстати, что порекомедуешь в качестве саундекса для русского языка и совпадает ли это с саундексом для транслитерированных на русский англосаксонских фамилий. И годится ли стандартный английский саундекс для немецкого/французского?

Еще интересно подумать над ассоциативным поиском по названию. В смысле искать по названиям, где перепутан порядок слов, какие-то слова запомнились не тем синонимом etc.

[painstakinglyyz.livejournal.com]

Ya poproboval copy-paste kusok koda, no k stidu svoemu ne znayu do sih por, kak eto sdelat' v ZhZh.

http://code.google.com/p/cutebookshelf/source/browse/trunk/parsers.py

Ostal'naya chast' proekta ne rasschitana osobo na polnuyu biblioteku Lib.rus.ec.

[vitus_wagner]

Cпасибо, распарсить метаинформацию из FB2 я сумею. Это на любом осмысленном языке несложно.
Сложнее придумать правильную структуру для складывания этой информации в БД, причем судя по объему и требованиям к памяти, тут нужна именно БД, например sqlite3 и ПРАВИЛЬНЫЙ ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ.

файловая система fuse для архива книг

[sastanin.livejournal.com]

У меня есть по этому поводу следующая мысль.

Решать нужно три задачи: сохранение и распространение имеющихся книг, организация удобного произвольного доступа к файлам отдельных книг и развитие и пополнение архива. С последней задачей либрусек пока ещё вроде справляется, поэтому наиболее насущны первые две.

1) Распространение. Эффективно — весь архив полностью торрентом (http://torrent.rus.ec/viewforum.php?f=186), но так неудобно для поиска и для получения отдельной книги. Удобно для чтения — находить по автору, жанру, названию — и скачивать по одной или несколько книг. Однако любой централизованный сайт будет или подавлен, или закрыт, или подкуплен (что и наблюдаем). В принципе, массовое пофайловое распространение возможно в P2P, оно децентрализованно, и может быть при желании и анонимным. Однако для P2P важно обеспечить одинаковые и описателные названия файлов и/или извлечение метаданных.

2) Организация произвольного доступа к файлам книг. Пока P2P не станет работающим и массовым вариантом, нужно работать локально с полным архивом. В большинстве случаев мне лично нужно найти искомого автора и затем уже выбрать из списка его книг. Реже — искать по названию или части названия. Предполагаю доступности полного архива (который в торрентах). В целях минимизации места на диске и удобства, желательно, чтобы программа доступа к книге умела работать с архивом именно в том виде, в котором он раздаётся в торрентах.

В связи с этим, меня привлекает следующее решение: user-space файловая система fuse, которая индексирует набор zip-архивов с fb2 и другими файлами внутри (а именно так распространяется архив). Пусть программа-индексатор извлекает из всех fb2 только метаданные. Используя эти метаданные, файловая система может представить архив в естественном библиографически упорядоченном виде. Для пользователя это будет выглядеть как иерархия каталогов, вроде такой:

/author/первая буква фамилии/фамилия и остальные имена, включая других авторов/название произведения/файлы
/genre/название жанра/author/первая буква фамилии/...
/genre/название жанра/title/первая буква названия/название/автор/файлы
/year/19xx/1950/author/...

Файлы при этом должны быть названы описательно, примерно так:

«Фамилия Имя Отчество. Название (Год) Издание.fb2»

При этом:

* для поиска отдельной книги в большинстве случаев хватит обычных средств работы с файлами (файлового менеджера или командной оболочки)
* основные пути поиска книги будут соответствовать вложенности каталогов
* возможны ортогональные иерархии, и по жанру, и по году, и по ISBN, и вообще по чему угодно; раз индекс метаданных уже раз собран
* ничего с самим архивом (85 ГБ на сегодня) делать не надо, его можно хранить и раздавать как есть, то есть массовое распространение библиотеки будет оставаться эффективным, сидов будет больше
* размер индекса, полагаю, будет невелик, а индекс будет меняться редко (старые zip-файлы не меняются, только добавляются новые)
* представление библиотеки в виде файловой системы никак не ограничивает ни выбор читалки, ни выбор полнотекстовых индексаторов (ежели кому-то они всё же понадобятся)
* представление всей библиотеки с библиографически организованной структурой каталогов и описательными названиями файлов, позволит людям легко выкладывать архив как в веб, так и в P2P (ну и вообще будет способствовать частичному, то есть удобному, человечному распространению книг) — и при этом можно раздавать и обновлять архив через торрент.

Мне кажется вариант почти идеальным. Если даже всего несколько десятков или сотен гиков откроют такую виртуальную ФС с библиотекой в P2P, почти любая книга будет легко находиться и быстро скачиваться вообще без централизованной библиотеки. При этом книги будут доступны не только гикам, но и вполне обыкновенным пользователям. За DDOSить такую систему распространения будет трудно. И всех читателей не подкупишь.

FUSE, пишут, есть и для maemo, так что решение может оказаться и вполне мобильным.

Наконец, отмечу, почему мне не нравятся все программы-каталогизаторы (в виндовом стиле), сама идея таких программ. Вместо нормальных полноценных файлов в них можно получить только элементы интерфейса. Это только если на десктопе с экрана читать. Даже взять и скопировать файл на флэшку или карточку памяти в них не всегда возможно.

Re: файловая система fuse для архива книг

[michael.ul.myopenid.com (from livejournal.com)]

Либрусек вполне справлялся с указанными вами задачами (как - другой вопрос), но оказался уязвим для копирастов. Организовать подобный сервис на базе p2p практически не реально, p2p плохо подходит для таких задач. Но на p2p свет клином не сошёлся. Есть ещё всякие darknet'ы. Почему бы, например, не организовать зеркало либрусека в anonet'е?

[silly_sad.livejournal.com]

"ну вы же программист! сделайте что-нибудь чтобы работало!"

[fantaseour.livejournal.com]

вопрос -- а нужны ли 200000 книг? Личная библиотека, это все же не свалка, а какой-то лично Ваш срез. У меня технической литературы 18 гигов, и я в общем-то обхожусь файловым менеджером. Мне даже актуальнее понятие книжной полки (как раз хотел сделать такую запись). Т.е. вытащил из библиотеки литературы на неделю вперед и имеешь быстрый доступ.

При том, что весь этот набор не цельно тяпнутый архив, а плод многолетнего коллекционирования, мне последнее время хочется библиотеку проредить. Есть книжки, которые особой ценности не представляют, вряд ли там написано что-то уникальное, и очень маловероятно, что я когда-то их буду читать. А поиск по книжкам они немного затрудняют -- файлов получается много. Запасаться заранее литературой "на всякий случай" интересное, но не очень практичное занятие.

Отдельный интерес -- "собрать абсолютно все книги". Это может быть интересно, как задача сама по себе. Тогда можно наверное исходить из узкой направленности задачи, спроектировать БД, не иметь в виду все это запихнуть в современную электронную читалку и т.д.

[vitus_wagner]

вопрос -- а нужны ли 200000 книг? Личная библиотека, это все же не свалка, а какой-то лично Ваш срез.
При нынешних ценах на носители дешевле в смысле затрат времени, иметь копию всего до чего дотянешься, и эффективные средства поиска в этой свалке, чем тратить время на формирование личного среза.
Запасаться заранее литературой "на всякий случай" интересное, но не очень практичное занятие.
Если под "всяким случаем" мы понимаем достаточно необычные информационные потребности, которые могут возникнуть там, где доступа к сети нет, "запасаться на всякий случай" единственное возможное решение.

[karpion.livejournal.com]

Я спрашивал про задачу "вот у меня есть на SD-карточке 200000 книг в формате FB2.

Для начала я бы попытался отказаться от условия "в формате FB2". В идеале хорошо бы хранить файлы в таком виде:

• Создаётся БД с перечислением всех употребляемых слов, благо слова постоянно повторяются.
• Слова кодируются исходя из правил языка: т.е. для существительных указывается само существительное, число и падеж.
• Слова кодируются так, чтобы часто повторяющиеся слова кодировались короткими последовательностями. Это классика, но не помню, имени кого.
• И сам текст, и БД для поиска содержат не сами слова, а тх коды.

Как тут уже скзали ло меня:

"ну вы же программист! сделайте что-нибудь чтобы работало!"

[vitus_wagner]

И почему это так никто не делает? Почему-то все используют коды символов, а не коды слов.

На самом деле ровно потому, что описанная схема существенно усложняет визуализацию, но нифига не экономит в смысле места. Ыот собственно, у нас индекс в словаре (4 байта, потому что двух мало) число (один байт) и падеж (1байт). 6 байт. Какой процент слов языка короче 6 букв? А с учетом частоты употребления?

Естественный язык, между прочим, весьма близок по своим свойствам к эффективному коду переменной длины. Правда, с учетом большой избыточности, необходимой для надежной передачи устной речи. Но эта избыточность легко отжимается обычным gzip-ом.

Стандарт Fb2, естественно, неоптимален. Но он весьма широко распространен, к нему написаны удобные программы чтения, которые решают задачу собственно использвоания книги. Остается только решить задачу найти нужную книгу по не совсем четко сформированным критериями и передать в читалку.

[besm6.livejournal.com]

Ничего лучшего, чем повторить форму поиска на сайте lib.rus.ec мне в голову пока не приходит

Мне тоже. Для наладонника весьма удобно.

[mikhailian.livejournal.com]

Поле genres в таблице books, содержащее конкатенацию каких-то кодов...

В Друпале очень часто поля таблиц используются для сериализации данных, по которым не планируется искать. И тем не менее, популярнейшая CMS. Может, не стоит судить по одному факту? В наше время RDBMS зачастую используется как тупейшее хранилище данных, где главное — простота, а о foreign keys и нормализации никто не вспоминает. Например, у Ruby on Rails такая политика.

[kmmbvnr.livejournal.com]

А разве Ruby on Rails сохраняет сериализованные объекты в бд, и про foreign keys constraint ничего не знает??

[wizzard]

я храню книги в eMule :)
но проблема быстрого доступа есть, да.

кстати, насчет бэкапа публичных хранилищ - что имеет смысл выкачивать\кравлить? могу потом захостить, если что

[vitus_wagner]

Все. Пока дают. Это пока - меньше сотни гигабайт всего. Десяток DVD болванок или 4 blueray. А то потом локти кусать будете, что была вот такая книга, да не прикопал вовремя.

[dm-ig.livejournal.com]

прикрутить sqlite-каталог к FBReader-у
По моему, идея весьма здравая. Не находите?

FBReader меня весьма радует как читалка, думаю, вы тоже им довольны. Так почему бы не помочь проекту?
Перевести хранилище на sqlite и приделать поиск по нему.

[vitus_wagner]

Нахожу. Но дело в том, что я туда уже ходил. Как раз в то место, которое занимается "каталогом библиотеки" sequence туда прикручивал. И у меня по опыту общения с кодом FBReader возникает подозрение, что сначала сделать отдельную приблуду, а уже потом, отладив интерфейс, думать о перетаскивании этой функциональности в fbreader - проще.

Да, конечно, ХРАНИЛИЩЕ на sqlite не переводить ни в коем случае. Вот хранилище метаинформации перевести из плоского XML-файла в sqlite - можно. И как-нибудь отучить freader при каждом входе в библиотеку проверять mtime всех файлов.

Впрочем, если в хранилище будут лежать zip-ы с либрусековского торрента, то файлов будет немного.

[afa-at-work.livejournal.com]

собирал на коленке каталогизатор - там с .fb2 еще одна пакость. процентов 10 файликов невалидны с точки зрения xml. пришлось регэкспами выкусить .+ нафиг.
а про полнотекстовый - сделал для любимых цитаток. потихоньку пополняемый и дополняемый в фоне.

[vitus_wagner]

НУ проблему невалидных XML rusec по крайней мере
заметил.
Так что может за месяц стало лушче.

К сожалению, там еще больше ЛОГИЧЕСКИ невалидных файлов. С неправильным разбиением на главы, с невыделенными эпиграфами и стихотоворнцыми цитатами, с полупустой метаинформацией.

[mincao.livejournal.com]

Гм. А что случилось с либрусеком?
Когда ты-таки сформируешь библиотеку, хотелось бы переписать :)

[vitus_wagner]

Ежели у alexkuklin бразуер не показывает перечеркнутый текст, то у тебя он, похоже, не выделяет визуально гиперссылки. Слова "либрусек окончательно скурвился" являются ссылкой на пост про то, что именно случилось.

мои ¢2

[nine_k]

Есть похожая задача, не раз решавшаяся: управление шрифтами. Пусть есть 10 тыщ шрифтов, держать их все установленными глупо, искать только по названию долго. Соотв. софт управления, в духе fontmatrix, позволяющий выделять группы, вешать теги, включать-выключать сразу группы или отдельные шрифты, смотерть информацию и образцы без установки, etc.

Вдруг какие идеи оттуда пригодятся.

Re: мои ¢2

[vitus_wagner]

У меня такой задачи ни разу не возникало. И есть подозрение что ни у одного вменяемого человека тоже. Потому что ни один вменяемый человек не будет использовать более четырех шрифтов в одном дизайне. Соответственно пары сотен хватит почти на любой случай.
А смотреть на решения созданные невменяемыми людьми мне неохота. Их и так на каждом шагу слишком много.

[painstakinglyyz.livejournal.com]

А какая интерфейсная библиотека сейчас наиболее кошерна под маемо? В смысле, чтобы и на старых, и на новых (которые скоро уйдут на Qt как основную платформу).

[vitus_wagner]

ncurses. Она была всегда и будет всегда.

[mkevac.livejournal.com]

О каком maemo идет речь? Nokia N900?

[vitus_wagner]

Нет конечно. У меня N800 и я не собираюсь ее менять на дурацкие слайдеры. Опять же, у более новых моделей Nokia нет полноразмерного SD-слота, (а у N800 их два). А если некуда воткнуть SD-карточку, весь разговор о таскании с собой библиотеки беспредметен.

[gegmopo4.livejournal.com]

Я для хранения и каталогизации использую файловую систему. Есть утилита (https://fb2-perl-tools.svn.sourceforge.net/svnroot/fb2-perl-tools/trunk/fb2-python-tools/fb2maketree.py), которая пробегается по списку файлов и строит дерево, основываясь на информации. Например, "язык/автор/название.fb2". Или "язык/серия : автор/номер. название.fb2".

Файлы не копируются, а делаются жёсткие ссылки, поэтому места дерево почти не занимает. Если у текста несколько авторов, то создаётся каталог и мягкие ссылки с каталогов отдельных авторов. Дерево на 7,5 тыс. файлов строится секунд за 13 (не считая сканирования ФС).

Теперь вот думаю, что следует разделить задачу. Отдельно сбор метаинформации (простая база: имя файла — метаинформация) и отдельно построение дерева. Тогда построение ещё быстрее будет. Да и простые запросы делать можно будет.