В сети online-конвертеров 100500 штук полно...

http://ebook.online-convert.com/convert-to-fb2

По уму всё равно нужно руками допиливать. Сомневаюсь я сильно, что сноски, картинки и форматирование корректно может сохранить автоконвертер.
То, что лежит на dotu, почти всё сделано автоконвертером и требует допила.

В любом случае, множество работ уже нормально сконвертировано.
Вопрос состоит в создании полноценной индексированной БД.

Мы базу делаем под MySQL? Или как?
Январь правильно говорит, нужно определиться как мы будем брать данные из базы.
1. Это даст нам ответ на вопрос какая база нужна.
2. Рисуем базу, её таблицы, размерность, типы данных. Становится понятен формат данных и платформа для реализации.
3. Тогда форматируем fb2 под поставленные задачи.
4. Параллельно пишем запросы и обработку для заполнения базы.

Все согласны?

1. Определяем типы хранимых данных:

1.а - Структура книги
1.б - Содержательная часть
1.в - Смежные данные

Подробнее:

Структура книги - абсолютно все от регионального и муниципального деления государства, от политического устройства страны и до книги можно описать с помощью структуры. Соответственно если задумано обращаться к элементу по указателям вроде DW.3.12.45 - то хранилище должно быть структурированным. Но тут возникает вопрос - а что именно следует хранить и с какой степенью детализации? Очевидно, что первый индекс в примере (DW - Dead Water) должен быть указателем на книгу, вротой индекс на главу, третий на раздел, подраздел, секция, параграф и т.д. Таким образом приходит понимание одной вещи - одна и та же таблица для упрощения выборки при полнотекстовой индексации должна хранить как структуру, так и содержательную часть, как название глав, так и содержание глав. Но хранение данных по параграфам - это слишком емко, по этому очевидно, что при степени детализации "параграф" заводить под каждую отдельную единицу новую запись - себе дороже, значит нужен общий парсер, способный рассчитать нумерации параграфов (или блоков в целом - параграфов, инсетов, таблиц, формул) для каждой главы (объемлющего хранилища)...

Вот это - принципиальная и наиболее сложная вещь по контексту замысла.

Ну а смежные данные - тут просто - это рубрикатор, категории, каталог событий, даты, теги и пр. и пр. и пр.

Решение:

Каталог книг - это таблица NestedSets, кроме прочих данных содержащая спец пометку для каждой записи, поясняющую, чем эта запись является - элементом структуры (книга, глава, подраздел) или же блоком содержания (содержание главы, хранящее много параграфов).

Это главное, а дальше проще:

Если некто ищет скажем: DW.5.17.19.3 - то по первому индексу мы находим книгу, а зная головной (топовый) элемент таблицы мы от него можем получить полное дерево (структуры) этой книги. Далее также никаких особых геморроев нет - если мы знаем топовый элемент, то получаем элемент второго уровня с индексом 5, из его ветки получаем элемент третьего уровня с индексом 17, из его ветки получаем элемент с индексом 19 и т.д.

То есть - все просто.

Далее - допустим у нас элемент 4 уровня с индексом 19 является содержательной частью. Значит нам надо найти в ней параграф №3 - как это сделать??? Еще проще??? Загодя для забивания книг в базу мы использовали редактор TinyMCE - он возвращает валидный хтмл, но при сохранении мы парсили его в промежуточный формат - наш личный XML... Когда перед нами встала задача найти третий параграф, мы читыем этот XML разбощиком и просто тупо берем узел "PARAGRAPH" с индексом 3... При желании мы можем и слово в параграфе найти - то есть тут проблем вообще 0...

...

Ну а смежники... Есть книга, у нее уникальный индекс DW и к ней пришиты доп.данные - категория = Социология, теги = ДОТУ, Заговор, Хомяки, авторы = ВП СССР, Январь ну и пр.

...

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

По вопросу сносок.

Я это вообще просто очень решил. Написал под TinyMCE плагин, добавляющий сноску. На место сноски он устанавливает спец.символ с номером сноски в рамках текущей объемлющей единицы структуры, а текст сноски записывает в реестр.

Уровень автоматизации получился таким: открываю книгу в MS Word, по оглавлению создаю ее структуру, потом кокипастом в узлы структуры заколачиваю текст, совершенно не заботясь о разметке, определение сносок, уничтожение вордовских спец.символов - все полный автомат...

... ... ... ... ...

Вот как-то так - по этому пути пошел я...

Ну и?..

И решил, что убить еще один проект - смысла нет в общем-то, по этому функционал будет включен в состав соц.сети...

...

Пример по выше написанному:

Допустим есть некоторая абстрактная книга "Шу и вайтмары". У нее уникальный альяс = Шу. У нее есть 3 главы: г.1, г.2, г.3. Вторая глава имеет содержательную часть.

В базе это выглядит так:

(id, alias, level, lkey, rkey)

1, Шу, 0, 1, 8
2, Г1, 1, 2, 3
3, Г2, 1, 4, 5
4, Г3, 1, 6, 7

Плюс вторая глава имеет содержательную часть:

...

Допустим кторо вводит "Шу.2.3".

По первому индексу (Шу) мы можем получить точное указание на головной узел (узел с id = 1), а все последующие индексы являются по сути смещениями.

И так, мы получили указание на узел:

1, Шу, 0, 1, 8

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

И так - ищем второй дочерний элемент по отношению к головному: мы точно знаем, что если уровень (level) головного = 0, то уровень его дочерних равен 0 + 1, то есть выбираем только из элементов с level = 1. Получаем 3 элемента. Нужен второй. Лимитами второй элемент получается элементарно.

И так общее правило - level = root.level + 1, lkey > root.lkey, rkey < root.lkey, limit index - 1, 1, при порядке сортировки по левому ключу...

То же самое верно для поиска третьего индекса, четвертого, пятого и всех остальных...

И так мы нашли элемент:

3, Г2, 1, 4, 5

Его содержательную часть читаем XML-разборщиком и выводим третий по счету узел, получаем - "Пыш".

В случае запроса "Шу.2.3.2" - получим "ы". В случае запроса "Шу" - получим дерево глав. В случае запроса "Шу.2" - получим все содержание второй главы.

... ... ...

На практике - прилетел запрос: "Шу.2.3" - разбиваем го на секции:

Нулевая секция - это всегда уникальный альяс книги, по этому ищем корневой узел этой книги:

Дополняем запрос так, чтобы одним запросом получить и второй узел (дочерний):

И так мы нашли вторую главу...

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

Так что... Но это по ситуации надо уже смотреть...

Всего-то ничего делов :mosking:

Январь, ты что предлагаешь всё в одной таблице хранить?

Нет... Структуры и содержания в одной - это понадобится для полнотекстовой индексации... А смежные данные в других каталогизаторных таблицах...

Разумеется...

Содержания конечно можно было бы вынести и в другие таблицы... Но - это доп. груз при поисковых запросах - соответственно вместо 1 полнотекстового поиска в поисковом запросе будет использовано минимум 2, а может и 3, а может и 4... Так что - проще в одной таблице хранить...

И да...

Тут еще забыли про вопрос длинны полей. Главу МВ не в каждый TEXT еще засунуть получится... Так что придется отталкиваться от LONGTEXT, но и он может не все обусловит...

Тут такое дело - в любом случае понадобится единый формат хранения, но - а как проводить поиск например по данным в формате XML??? И, но если в XML хранить 1 параграф, то длинна записи автоматом увеличивается на 7 единиц - и это не считая стилизации (прочей)... То есть - на выходе можно таки получить текст, чья длинна увеличена в 1.5-2-3 раза относительно полезного содержания. И опять же - как это индексировать? Хранить аналоги? Тогда как хранить таблицы, как выделять сноски?

Так что - решайте...

Я то - хо хо хо!!!

Решайте - кто?

Кто у нас тут айтишник с ааафигенной зарплатой, я или ты?!

Я на пальцах могу объяснить, чего надо. ТЗ называется.
А чё как индексировать - это ты решай.

Таблицы и сноски хранить в полях с типом Blob + добавить ещё одно поле(ТипБлобов) в котором будет информация - какого типа данные хранятся в блоб: 1-текст(сноска) 2- картинка(формула).

Январь в запой ушёл, как понял, что работа наклёвывается...

А не проще ли нам из каждого fb2 сваять html и связать их все в сайт. А поиском будет заниматься Яндекс, Гугл и другие страшные аббревиатуры.
Это мы и сами легко сделаем.

Мысль понятна.
В ответ могу перечислить проекты, которые люди тянут годами и не жалуются.
Разумеется, с таким настроением делать что либо безперспективно.

Это уже делает, скажем, Миха.
Но на мой взгляд, это безполезная работа.
HTML - это мёртвый вариант. С этим куском информации толком ничего больше не сделаешь.
А индексированная база данных - это гибкая и живая информация, из которой тот же HTML сделать - дело нескольких минут. А можно exe-шник сделать со встроенной читалкой. А можно на другую платформу перегнать. А можно цитату сделать выборкой информации.
Это перспективная работа.

Что такое МФ? Я не знаю. Но реализовать сквозной поиск по работам КОБ+ возможность автоматизировать процесс создания текстов для е-книг и аудио читалок - разве это никому не нужно.

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

Такое ощущение, что тебе вообще вся эта байда(материалы КОБ, да и сами вы) не нравится.

Молодец, Январь:bj:. Спасибо за хорошие идеи по реализации.
Удачи в умирающей индустрии соцсетей:do:.

Дорогу осилит идущий:ay:.

Таким образом я не понимаю, что делать. С чего начать?
Судя по всему нужно взять у Января базу для тестов и пробовать прикручивать к ней интерфейс сайта с выводом и поиском для любой платформы. Даст?

&!@#$^%#$%^%$&^(%^&!@#^%$^#$@&

:)

Что самое сложное в задуманном???

Правильно - занесение книг в базу - это самый длительный и pутинный процесс... Сделать сайт - надо, но это пятое-десятое дело. Для начала надо разобраться с тем, что собственно на этом сайте будет публиковаться.

По этому главное (на мой взгляд):

1. Реализовать редактор, который позволит максимально просто перегонять книги из формата Word в XML для хранения в базе (редактор можно взять у Января, + можно заказать свои собственные хотелки под интерактив редактора, Январь их реализует в виде доп. плагинов к редактору).

2. Реализовать базу, которая будет хранить структуры книг и их содержания (при желании реализацию так же можно взять у Января).

3. Реализовать процесс заполнения базы, то есть сделать интерфейс для перегонки книг в базу.

4. Реализовать базы сопутствующих данных, чисто на вскидку это - теги, рубрикатор, события.

5. Собрать команду, которая приступит к заполнению базы.

6. Реализовать сайт и поиск в соответствии с задумками Сирина (при этом специфические модули поиска можно взять у Января)...

Наверное в этом нет ничего сложного. Просто я никогда не делал сайт с базой данных. Потому представляю это весьма поверхностно и не знаю с какой стороны подойти. Какой софт поставить, нужно ли выделять отдельную машину? Поставил пока виндовую виртуалку, хочу на неё повесить 2003 с sql2000. Что я ещё слышал? TinyMCE найду. Что ещё понадобится? Вывали софтоссылки или хотя бы перечень нужного софта.
Товарищи, чем будем сайт делать?
Давайте определимся, что будет делать сайт, чтобы конкретно начать делать базу данных.
Какой у него будет функционал.
Давайте соберём хотелки по сайту. Нарисуем. Тогда станет понятен конечный вид базы.
И можно будет с ней работать.

:D http://tinymce.com

Да и - я ж грю - дам с готовыми плагинами...

На самом деле надо сделать 3 вещи:

1. Выпросить у Сирина доступ к серваку, в папку где будет стоять сайт.
2. Выпросить доступ к базе.
3. Залить собственный phpMyAdmin.

И все... Все что надо на серваке уже установлено...

:ay:

В этой ветке все описано.

Кстати кобекам (так я ласково называю вменяемых кобзойдов) стоило бы ознакомиться с методологией scrum (есть на wiki) и с каким-нибудь из средств управления, поддерживающих scrum, например с jira (есть на wiki)...

Может быть тогда контроль разработки и сопровождения проектов был бы эффективнее!..

Есть... Есть и из Excel в html... И из PDF есть... Но нас все это не интересует, нас интересует специфический XML-разборщик... Кстати - а у JavaScript-Бога и на жабоскрипте такие конвертеры есть :) ...

Я ж почему тинимси и предлагал - бо это сделать как 2 пальца абассать!..

Ню?

Гню.

Покажи свой парсер в работе.

:crazy:Точно, только этого нам не хватало....

Ммм? Зачем???

Вообще опыт других редко бывает лишним. Буржуи то может и буржуи, и пожиратели трупов, но тем не менее вряд ли кто будет утверждать, что они не эффективно организуют производство...

Кстати - если будет такой сайт, будет целесообразно под него тулбары для бравузеров написать. Будет совсем удобно... Я могу для ФФ, Кх, Оп и Сф написать... Для Ие не могу... Потому что Ие по традиции черезжопен...

Ппрррррррррррр...

Жире то вообще пофиг каким алгоритмом ПО выпускается.

Я говорю о систематизации учета, а не о техническом подходе...

up

ну понятно

Январь, зафлудить тему я и сам могу.

По сути дела есть что сказать?
База и доступ уже есть.

КАК ЧТО и КТО будет делать?

+ разъясните мне, зачем на данном этапе нужен отдельный сайт, если речь идёт о разработке универсальной БД?!

Вот это как раз я спрашиваю...

Если сайт не нужет то и нафиг его. В любом случает нужна площадка на которой будет стоять интерфейс заколачивания книг в базу... Это может быт develpment.kob.su например - вообще не принципиально... Принципиально то, что он должен быть, а его нет...

А что, тестовые испытания уже пройдены?
База готова, инструкция по заполнению написана, дизайн форм разработан и выпущен?

Вот и я о том...

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

Для начала нужно ТЗ написать.

Ребят, а вообще нужна ли такая база с возможностью поиска по работам ВП СССР? Вы цитатами собираетесь закидывать кого-то?

Для индексирования поисковиками ничего делать не нужно. На многих сайтах выкладываются те же самые тексты в формате чистого HTML, а на e-dotu в виде читаемого веб-текста. Все поисковики это видят, а гугл индексирует ещё и все doc, odt и fb2 файлы. Кому нужно будет - найдёт.

Может быть лучше не заниматься задрачиванием текстов ВП СССР, а заняться действительно важными делами, такими как: изменением своей нравственности, применением полученных знаний в своей личной профессиональной и творческой деятельности.

Тогда расскажи в какой работе ВП говорится о том, кто убил Распутина?

а это реально важно знать ?????????????????

Я вот не пойму - никто так и не понял о чем я говорю, или все претворились, что не поняли о чем я говорю?..

Вспомнил притчу от Зазнобина про про смену вод и мужика в пещере :crazy:

Да в том и дело что не знаю... Хочу прочитать, а что читать не знаю... Не возможно же быстренько перечитать все работы сразу... Для того и нужен поиск...

Помнится мне, Евгений обещал написать ТЗ когда-то. Есть надежда?

:D

---

Я кратко:

1. Как я и ранее говорил - я не буду осуществлять сборку, у меня на это просто времени нет, мой долгострой - повис, вагранси - упал, на работе до декабря в МТС еще один проект надо сдать, строю дачу, опять же - ребенок...

2. Посему - напомню - было бы не плохо, если кто-то собрал бы сайт, где все это будет крутиться...

3. Я же - дам редактор под этот гемор, который автоматизирует часть работы (процентов так 70) по набору базы...

4. К нему я дам систему управления рубрикацией...

5. Структуру базы под хранение архива книг с привязкой к рубрикатору...

6. Механизмы поиска, те, что описывал Сирин...

7. Ну и конвертеры: doc -> pdf -> fb2 -> html и в любом порядке - подгоню...

Но - я не буду собирать все воедино...

Но - я при необходимости помогу расширить функционал редактора до любых степеней - видио, аудио, фото, графики, автоформаты и автозамены, способы элементарного добавления сносок, создание структур неограниченной вложенности (например если хоть память мне не изменяет - у МВ то ли 4 то ли 5 степеней вложенности. А, стапудово - у МВ - 5 степеней, а у ОС всего 3 и т.д.)...

Короче - ну так чо там каво???

Поиск по книгам
 

Организация поиска по книгам это довольно масштабный проект... И честно говоря я не вижу смысла в его реализации.

Главная задача на мой взгляд это накопление и распространение библиотеки материалов.

А поиск по книгам можно использовать и от Google (books.google.ru). Книги ВП СССР в нем отлично проиндексированы. Там даже можно ссылки делать и встраивать страницы на сторонние сайты...

Вот например:
Ссылка

Насчёт главности задачи могу поспорить, но не суть.
Чем реализация "главной" задачи мешает реализации сопутствующих?

Покажите, как мне встроить отдельный абзац по выборке?

Как мне пользоваться этой базой на планшете, ноуте или смартфоне, проводя отпуск в деревне Плюевка Загорянского уезду Самарской губернии, куда интернет проведут лет через 70?

Смысл не столько в поиске, сколько во фрагментарной выдаче...

Если гуглу скормить строчку, он найдет ее в книге, но если гуглу скормить индекс строки - он ничего не найдет...

В том и вся фишка, чтобы реализовать поиск не только по строкам, но и по индексам вроде DW.14.123.19.12-17 ... У гугла же это реализовано лишь на уровне закладок. Сделал закладку - можешь потом ее найти, не сделал, не можешь...

А здесь считай любая занесенная в базу книга автоматом разложена для вида, понятного поисковому механизму и ни с какими закладками ты не заморачиваешься!

Такого еще нет. То есть - такого ВООБЩЕ еще нет...

Потому и нет, что гугол, несмотря на все его недостатки, ориентируется на массовую аудиторию обычных пользователей, а не на узкую прослойку гиков.
А гики вообще не читают ВП СССР, получается сделаешь только для себя, любимого, чтобы показать что могЁшь.

Уже 1000 раз говорили, что рубрикация нужна ИМЕННО для того, чтобы не создавать базу работ одного только ВП СССР, а иметь возможность заносить хоть все подряд - хоть Старикова, хоть Сироткина, хоть Ходоса...

То, что заносить и хранить в базе проекта коб.су - решит Сирин, но например Миха может быть захочет хранить женские романы, а Шу новую хронологию ФиН, а РЛС книги по военной истории...

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