Не понял. Есть же BookSeer (http://www.msolt.chat.ru), который все это делает. Зачем изобретать велосипед? Ему только не хватает возможности работать в онлайне. Но соответствующую приблудку для этого разработчик М. Солтанович уже изобрел. Думаю, до конца года буксир станет полнофункциональным, т. е. одинаково работающий как офлайн, так и онлайн каталог.

У меня два вопроса не по теме:

1) Что такое "транспортный формат"? (и соответственно какие форматы "нетранспортные")

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

2) Где можно посмотреть сайты ОСR-онлайн и сайты совместной вычитки? Очень интересно.

Онлайн OCR-вычитка -- это прежде всего проект "Гутенберг".
http://pgdp.net. Английский. Зарегистрируйтесь и посмотрите.
Интерес там представляет практика и последовательность обработки: 1 юзер там по сути не считается авторитетом, вот если 2 и больше грамотных юзера сходятся во мнении, то оно и становится авторитетным (я имею в виду корректуру). У нас же -- пока каждый сам по себе.

Насчет транспортного: его отличие от архивов с ихними diz'ами. По сети могут передаваться не только файлы, но и информация. Вот и попробуй передать в современном архиве информацию, воспринимаемую без ручного парсинга _всеми_ любительскими программами-библиотекарями да и сайтами тоже с помощью _одного_ шаблона.
Транспортный формат обязан быть нацелен на передачу информации. Текст книги -- частный случай. Исправления к тексту -- тоже частный случай. Совсем не обязательно, чтобы пересылался весь исправленный текст, а вот список очепяток пересылать надо и здесь есть по сути два варианта -- либо уникальный фрагмент текста в книге предлагается заменить на исправленный с поддержкой стандартных регулярных выражений, либо текст идет уже отформатированным по жестким стандартам, например fb2, и можно указывать физическое размещение исправляемого текста -- абзац/элемент такой-то, символ номер такой-то заменить на то-то; первый вариант более универсален, но тоже требует от программы управления библиотекой понятия, что это и есть список очепяток. Вот как раз разрешения вопросов по интерпретации списка прикрепленных файлов и информации и надо ждать. Наиболее известный пример транспортного формата -- это email, хотя там нет описания файлов, а только указания их типа.
Наверняка есть некий ISO-стандарт на обмен между библиотеками библиографической информацией по стандартам MARC. Там, в этом MARC, кстати, >900 полей.

Наиболее логично совместить библиографическую информацию с каталогом "Сервера каталога". На конкретной библиотеке вполне может урезанный вариант: список публикаций с дешифровкой их содержания. Практически все читатели обычных библиотек как раз с таким уровнем и работают. Да и для цифровых библиотек нечто большее требуется лишь одному из 1000.
Вот к примеру, примерная схема таблиц библиограф. БД:

Расширенная информация об авторах (опционально) <=> АВТОРЫ <=> Список авторов произведения <=> ПРОИЗВЕДЕНИЕ <=> Содержание публикации <=> ПУБЛИКАЦИИ <=> Расширенная информация о публикации (опционально)

Выборкой из этой БД цифр.библиотеки будут строить свои каталоги по схеме:

ПУБЛИКАЦИИ <=> Содержание публикации.

Схема, естественно, для самых простых библиотек, впрочем каталоги совр. цифр. библиотек не отличаются от нее, только в некоторых добавлена дополнительная информация об авторе.

Реализация вообще проекта как можно заметить требует достаточно мощного центр.сервера либо придется данный сервер использовать как переопределяющим запрос на один спец. серверов. Причина: на данный момент доступно по моим оценкам около 1 млн. произведений (не публикаций! -- их во много раз меньше) только худ.литературы. Реализация сервера способного справиться с большим кол-вом запросов к такому каталогу вещь весьма дорогостоящая.
Реализация серверов архивов гораздо менее требовательная задача, т.к. обращений к ним со стороны читателей не будет, за исключением запросов на произведений не пользующихся спросом, которые хранить в постоянном доступе в цифр. библиотеках нерентабельно.

primus, вот мысли насчет поддержки. Вы никогда не задумывались, где все это висит и сколько стоит оплата?
Ведь виртуальный сервер чаще всего имеет ограничение по выделенным процессам, обычно такие сведения на хостингах редко указывают, например, valuehost даёт одновременно на своих серверах открыть для одного сайта не более 25 одновременных процессов, читай -- это где-то 10-12 пользователей. Конечно, реально необходимо оперировать более длительными промежутками времени, т.к. запросы от разных пользователей распределяются во времени, но реальна поддержка одновременной работы ~250 подключений, большее количество уже значительно увеличит время ожидания ответа сервера, что может раздражать Вас. На превый взгляд это много, т.к. полазив по сайтам библиотек можно узреть из статистики, что одновременно может на сайте болтатеся в лучшем случае 50 юзеров. Можно найти и с большим количеством процессов, но при этом и плата растёт в разы (до 10 и более раз). Для крупных баз данных единственной панацеей является выделенные сервера, причем для надежной работы необходимо иметь резервный дублирующий сайт. Предлагается же аренда серверов от 80 у.е. в месяц (это нечто вроде современного стандартного офисного компутера), реально же нужно ориентироваться на гораздо более мощную и дорогую технику. Я, например, оцениваю минимально необходимые траты для создания единого прожекта порядка 20000 - 30000 рублей в месяц. По одной причине: здесь нужно добрых 10-15 виртуальных и выделенных серверов для обеспечения бесперебойной работы. Вешать на один сервер все нецелесообразно, нужно для начала как минимум 2.

Конечно, вы можете сказать, что сайт Мошкова крутится на меньших требованиях, но это уже сейчас менее 5% доступного объёма. И будет еще меньше. Реально сейчас нужно проектировать под 10Гб (в архивах) активно пользующегося спросом контента и 100Гб пользующегося редким спросом.

Что тут можно дешевого предложить? Нечто вроде FTP-mail + огр. рассылка. Т.е. в рассылку брякается все новое, которое и складируется у подписчиков, а также на наборе из 10-20 дешевых серверов по некоторым жестко определенным принципам, а читатель работает с языком аналогичным FTP-Mail. Скорость ответа конечно будет мизерной. Зато и требования к серверам архивов минимальны, т.к. от них будет требоваться только передать файл/листинг на сайт обработки запроса Lib-Mail.

К сожалению, хостеры типа PeterHost, предлагающие избытки дискового пространства на своих серверах для создания простющих статичных сайтов за копейки (150руб. за 15 Гб в месяц) мало подходят для хранения архивов именно из-за простоты, т.к. защитить их от сободного доступа (что к сожалению будет требоваться) невозможно.
Впрочем, сразу говорю, что я не специалист по данным вопросам и по оценке нагрузки, и такие мысли у меня появились после ознакомления с FAQ-ми по хостингу.

В общем-то, проблема единой базы не только в создании единого каталога, но и в обвязке его железом.
И вот здесь, звиняюсь, полезет крамольная мысль: не отдать ли это все на откуп профессионалам? Ведь платный доступ для он для конкретного лица подешевле будет, загвоздка лишь в том, чтобы нас пустили как участников процесса, имеющих ряд преимуществ, чего не наблюдается. Да еще в проблеме наступающего ну не монополизма, но реального картельного сговора. Поэтому и лезут всем мысли об отдельном независимом процессе _вне_ этих структур. Вынуждено. Просто деваться некуда.