Автор Тема: Программа для генерации наименования и метаданных DjVu и PDF  (Прочитано 18113 раз)

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Снова заработал форум http://gen.lib.rus.ec/forum/

Сижу пока читаю там топики - на предмет почерпнуть какие-то соображения для будущего стандарта именования DjVu и PDF-файлов.

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

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

Думаю, что для всех этих языков тоже есть некие стандарты транслитерации. Так что, как мне кажется, для книг на любом языке имя файла следует писать на транслите (латинские буквы и обычная ASCII-кодировка).
« Последнее редактирование: 15 БХЭвпСам 2010, 12:09:11 от monday2000 »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Интересная проблема - как назвать файл, если в названии бумажной книги присутствует символ двойной кавычки ". Ведь в Windows этот символ не может быть в имени файла.

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
По поводу метаданных в DjVu.

Оказывается, XMP-метаданные в DjVu ещё не одобрены официально компанией Caminova (владелец формата DjVu).

Официально одобрены пока только PDF DocInfo - метаданные. Точнее, их поддержка внедрена в DjVu Shell Extension Pack - официальный продукт от Caminova:

http://dev.caminova.jp/beta/djvu-wic/
Цитировать
Now uses PDF DocInfo compatible property names to conform to the djvuchanges.txt.
Эти же метаданные поддерживает (отображает) DjVu-просмотрщик DjView - из состава DjVuLibre.

Причём метаданные может иметь как весь DjVu-файл в целом - так и (дополнительно) каждая отдельная страница многостраничного DjVu-файла.

Вот пример скрипта для djvused, позволяющий внедрить в любой DjVu-файл PDF DocInfo - метаданные:
select; remove-ant; remove-txt
# -------------------------
select 1
set-ant
(metadata
    (Author    "Phil Harvey1")
    (Title    "DjVu Metadata Sample")
    (Subject    "ExifTool DjVu test image")
    (CreationDate    "2008-09-23T12:31:34-04:00")
    (ModDate    "2008-11-11T09:17:10-05:00")
    (Keywords    "ExifTool, Test, DjVu, XMP")
    (Producer    "djvused")
    (Trapped    "Unknown")
    (Creator    "ExifTool")
    (url    "http://owl.phy.queensu.ca/~phil/exiftool/")
    (note    "Must escape double quotes (\") and backslashes (\\)")
    (annote    "Did you get this?") )
.
Этот пример взят от автора ExifTool - редактора метаданных для множества форматов.

Из этого примера виден набор полей, поддерживаемых спецификацией PDF DocInfo.

В общем, я к тому, что запись PDF DocInfo-метаданных в DjVu файл уже можно реализовывать в своей программе. А вот надо ли реализовывать ещё и дополнительно XMP-данные для DjVu-файлов - пока неясно.

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Я создал аналогичный топик на форуме либгена:

http://gen.lib.rus.ec/forum/viewtopic.php?f=6&t=786

Попробую также и там обсудить эту тему (если получится, конечно).

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Вот мне один человек прислал письмо по теме:
Цитировать
очень полезно начинание.

Предлагаю начать с определения цели зачем это надо.

Понятно, удобочитаемые имена - полезно. Но для чего? Как по мне - то
чтоб видеть что в файле через любой файловый менеджер.
В задаче есть понимание важности метаинформации и предлагается сразу
же, при формировании имени запихивать ее в сам файл. Кстати, придумали
также спец. метафайл, содержащий только дескрипторы fb2, назвали его
fbd. Предлагаю сразу и туда.

Но, как минимум, половина дальнейших рассуждений связана с требованием
"обратимости" имен, т.е. решением обратной задачи - извлечение из
имени метаинформации. Вот здесь, как по мне, и зарыто противоречие. А
именно - зачем извлекать метаинформацию из имени, если это можно
сделать из спец.полей файла или из спец.файла для метаинформации
(fbd)? Туда же все уже запихнуто вместе с формированием имени. Причем,
без всяких преобразований и искажений.

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

Ну и одно замечание что пихать в имя файла. как по мне - что что
угодно, т.е. это должен определять юзер, главное - чтоб имя файла без
проблем поддерживалось ВСЕМИ файловыми системами. Ессно, на
современном уровне:). Но один элемент - обязательно. Это ИСБН.

Потому как по этому номеру всегда можно получить метаинформацию из
он-лайновых баз данных. Судя по всему, у автора не совсем правильное
понимание что это такое, потому как ИСБН упоминается рядом с УДК, ББК
и т.д. Это принципиально разные вещи. ИСБН можно рассматривать как
уникальный код, однозначно определяющий набор метаданных типа
названия, авторов, данные об издании и т.п. Ессно, это немного
произвольная трактовка, звиняйте, но, по-моему, принцип оно отражает:)
Ну, т.е. ИСБН - это те же метаданные, но закодированные в виде набора
из 10 или 13 символов. И "раскодировать" их не представляет никакого
труда.

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

kv

  • Новичок
  • *
  • Сообщений: 11
    • Просмотр профиля
    • E-mail
Привет всем!
Выше мое письмо - не знал про здешний форум, увидел задачу на либгене, а там траблы на форуме продолжаются:)

Как вам предлагаемое изменение постановки задачи?
« Последнее редактирование: 16 БХЭвпСам 2010, 13:02:58 от kv »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Отвечаю на письмо:
Цитировать
Понятно, удобочитаемые имена - полезно. Но для чего? Как по мне - то
чтоб видеть что в файле через любой файловый менеджер.
Да, именно для этого. И чтобы, не скачивая книгу, по её имени понять, что это за книга.
Цитировать
Кстати, придумали также спец. метафайл, содержащий только дескрипторы fb2, назвали его fbd. Предлагаю сразу и туда.
Пока не вижу смысла. Зачем "сразу и туда"? Во-первых, это в принципе не нужно, а во-вторых - всегда потом нетрудно будет сделать. Но вообще метаданные будут записываться одновременно - с формированием "говорящего" имени файла.
Цитировать
А именно - зачем извлекать метаинформацию из имени, если это можно сделать из спец.полей файла или из спец.файла для метаинформации (fbd)? Туда же все уже запихнуто вместе с формированием имени. Причем, без всяких преобразований и искажений.
Смысл есть. А что, если кто-нибудь не захочет пользоваться метаданными - по не важно какой причине? Например, просто не знает, что такое метаданные - и никак не может это понять. Или же не имеет специализированный софт для работы с PDF и DjVu-метаданными. Пример: кто-то захочет на веб-сервере реализовать именование файлов (по новому стандарту). Станет ли он заморачиваться ещё и реализацией поддержки PDF и DjVu-метаданных? Наверняка нет. Ведь метаданные в PDF и DjVu имеют строго предопределёный формат (т.е. набор полей). Абы какие метаданные (FB2-метаданные) в PDF или DjVu вставлять не положено.
Так что отказываться от обратимости имени файла в метаданные (естественно, частичной) не хотелось бы.
Цитировать
Ну и одно замечание что пихать в имя файла. как по мне - что что
угодно, т.е. это должен определять юзер, главное - чтоб имя файла без
проблем поддерживалось ВСЕМИ файловыми системами. Ессно, на
современном уровне:).
Тут у меня пока нет своего чёткого мнения. А зачем юзеру пихать в имя файла что попало (всё, что ему захочется)? Тогда автоматический разбор имени файла не получится. Пусть взамен юзер пихает "что попало" в метаданные - а не в имя файла. Тогда проблем никаких. Там места много, и полей данных достаточно.
Цитировать
Но один элемент - обязательно. Это ИСБН.
А вот это как раз не обязательно - по той простой причине, что не у каждой книги он есть вообще. "Не обязательно" - но "крайне желательно", я так полагаю.
Цитировать
Судя по всему, у автора не совсем правильное понимание что это такое, потому как ИСБН упоминается рядом с УДК, ББК и т.д.
Да, конечно, я не силён пока в этих вещах.
Цитировать
Ну и, если дополнение к исходной задаче в виде убрать требование
обратимости имени будет принято, тогда можно продолжать.
Ну а если нет - то я пас. Потому как в этом случае я считаю что задача
нерешаемая.
Убирать не хотелось бы. А почему именно нерешаемая? Из-за того, что тогда нельзя будет помещать в имя файла произвольную информацию?

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

kv

  • Новичок
  • *
  • Сообщений: 11
    • Просмотр профиля
    • E-mail
Цитировать
Цитировать
Понятно, удобочитаемые имена - полезно. Но для чего? Как по мне - то
чтоб видеть что в файле через любой файловый менеджер.
Да, именно для этого. И чтобы, не скачивая книгу, по её имени понять, что это за книга.
согласен. Ну дык и оставить только єту цель. Потому как чем проще задача - тем больше вероятность ее решения.
Цитировать
Цитировать
Кстати, придумали также спец. метафайл, содержащий только дескрипторы fb2, назвали его fbd. Предлагаю сразу и туда.
Пока не вижу смысла. Зачем "сразу и туда"? Во-первых, это в принципе не нужно, а во-вторых - всегда потом нетрудно будет сделать. Но вообще метаданные будут записываться одновременно - с формированием "говорящего" имени файла.
когда делать - другой вопрос, главное чтобы можно было. Главный резон - уже есть каталогизаторы, что понимают этот формат. Например, http://home-lib.net. Если есть набор таких файлов рядом с книгами. остается натравить его на каталог с файлами - а дальше все будет сделано само.
Цитировать
Цитировать
А именно - зачем извлекать метаинформацию из имени, если это можно сделать из спец.полей файла или из спец.файла для метаинформации (fbd)? Туда же все уже запихнуто вместе с формированием имени. Причем, без всяких преобразований и искажений.
Смысл есть. А что, если кто-нибудь не захочет пользоваться метаданными - по не важно какой причине? Например, просто не знает, что такое метаданные - и никак не может это понять. Или же не имеет специализированный софт для работы с PDF и DjVu-метаданными. Пример: кто-то захочет на веб-сервере реализовать именование файлов (по новому стандарту). Станет ли он заморачиваться ещё и реализацией поддержки PDF и DjVu-метаданных? Наверняка нет. Ведь метаданные в PDF и DjVu имеют строго предопределёный формат (т.е. набор полей). Абы какие метаданные (FB2-метаданные) в PDF или DjVu вставлять не положено.
Так что отказываться от обратимости имени файла в метаданные (естественно, частичной) не хотелось бы.
по порядку. Если кто-то не захочет пользоваться метаданными - пусть не пользуется, никто не заставляет, но вот подменять понятия - в данном случае "метаданные" подменять именем файла не надо никогда, потому как это неправильно в принципе.
Если кто-то не знает, что такое метаданные, то пусть выучит что это, а не изобретает велосипед. Потому как потом хаоса будет больше и порядок в нем наводить гораздо труднее, нежели изначально его не плодить. Во-вторых, метаданными имеет смысл пользоваться только для создания базы. А если понимание дошло до того, что база - нужна, то и понятие "метаданные" уже не будет открытием.

Цитировать
Цитировать
Ну и одно замечание что пихать в имя файла. как по мне - что что
угодно, т.е. это должен определять юзер, главное - чтоб имя файла без
проблем поддерживалось ВСЕМИ файловыми системами. Ессно, на
современном уровне:).
Тут у меня пока нет своего чёткого мнения. А зачем юзеру пихать в имя файла что попало (всё, что ему захочется)? Тогда автоматический разбор имени файла не получится. Пусть взамен юзер пихает "что попало" в метаданные - а не в имя файла. Тогда проблем никаких. Там места много, и полей данных достаточно.
Например, у меня есть электронная читалка и я хочу рассортировать книги в одном каталоге, но чтоб видно было к какой серии (том, издание) они относились. Здесь в имени надо ставить сначала серию, потом - автора. Для другой читалки требования могут быть другими.
Цитировать
Цитировать
Но один элемент - обязательно. Это ИСБН.
А вот это как раз не обязательно - по той простой причине, что не у каждой книги он есть вообще. "Не обязательно" - но "крайне желательно", я так полагаю.
ессно, если ИСБН есть. А на нет - и суда нет:) Тем более, что ИСБН не читаем, и будет дополнением к имени где есть нормальное название. Ну а нету ИСБН у книги - и не будет этого куска.
Цитировать
Цитировать
Ну и, если дополнение к исходной задаче в виде убрать требование
обратимости имени будет принято, тогда можно продолжать.
Ну а если нет - то я пас. Потому как в этом случае я считаю что задача
нерешаемая.
Убирать не хотелось бы. А почему именно нерешаемая? Из-за того, что тогда нельзя будет помещать в имя файла произвольную информацию?
1.основная причина этого - в  разной природе данных.
Имена файлов - короткие - до 255 символов
сюда входят также путь до корневого каталога библиотеки, а это - величина переменная для каждого юзера
2.кодировка-транслитерация. Вобчем, нет ни одного стандарта, где бы описывалась транслитерация ВСЕХ символов. Потому что сейчас транслитерация как таковая уже не очень актуальна. Так, ошметки старых технологий. Все новое и в юникоде прекрасно живет без всякой транслитерации. Т.е. здесь придется городить некий гибрид, трудоемкость создания которогону очччень большая, а смысл?
3.разделение полей в имени. Нормально это только тегами можно сделать, у тебя это токены, но они тоже занимают место, и это все - из тех же 255 символов. А если ты хочешь в имя запихнуть много полей, то у тебя получится, что от трети до половины длины имени уйдет на сами токены. А они ж нужны не для того, чтоб видеть, т.е. для главной задачи, а только для разбора. Т.е. причина - в смешении двух задач в кучу. И в том, что эти задачи - противоречивы.
4.опыт. Работал много на почве создания база данных из имен файлов. Типа, занимался как раз той обратной задачей - извлекал метаданные. И не видел ни одной системы именования, чтобы она позволяла однозначно решить задачу. В лучшем случае будет потеря метаинформации, в худшем- обрезание и смешение разных типов.
Цитировать
Но возможен и компромисс: предусмотреть в конце файла опциональный раздел с произвольной информацией (где юзер будет иметь полную свободу). Этот раздел не будет парситься автоматическим каталогизатором - при разборе книг - ну да и ладно, автоматическому парсеру вполне хватит имеющихся жёстко предопределённых полей.
каталогизация - это совершенно другая задача. ПРичем уже во многих отношениях решенная - см. тот же хокм-либ. Такох прог еще с десяток найти можно. У всех у них основная проблема - где брать метаинформацию, все решают по разному, ну дык и пусть берут ее с фбд файлов. А курочить имена они до сих пор не научилсь. Так почему ты думаешь, что научатся в будущем?

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

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kv
Цитировать
Главный резон - уже есть каталогизаторы, что понимают этот формат. Например, http://home-lib.net.
Ещё раз повторюсь: форматы PDF и DjVu поддерживают строго предопределённый формат метаданных - т.е. фиксированный набор полей (с предопределёнными именами). И никакой иной формат метаданных (из FB2) применять для форматов PDF и DjVu недопустимо.
Цитировать
Если есть набор таких файлов рядом с книгами. остается натравить его на каталог с файлами - а дальше все будет сделано само.
Набор файлов рядом с книгами - это вообще некрасивое решение. Для этого существуют метаданные.
Цитировать
Например, у меня есть электронная читалка и я хочу рассортировать книги в одном каталоге, но чтоб видно было к какой серии (том, издание) они относились. Здесь в имени надо ставить сначала серию, потом - автора. Для другой читалки требования могут быть другими.
А это уже совсем другой вопрос - не имеющий к рассматриваемому никакого отношения. Пусть это будет головной болью конкретного юзера - а не нашей. Нужна ему некая иная схема именования - так это его проблемы - при чём здесь мы? Нас волнует только то, как упорядочить книги в больших онлайн-библиотеках - И ВСЁ.

Я-то подразумеваю, что мы тут создаём формат именования файлов для больших онлайн-библиотек (и для хранения на DVD их в скаченном виде). А пользователь у себя на компьютере потом пусть переименовывает файлы так, как ему хочется, и как ему вздумается. Естественно, универсальная система именования на все случаи жизни невозможна.
Я же взял за основу программу Name Creator http://www.djvu-soft.narod.ru/soft/namecreator.htm - она существует уже много лет, и как известно, вполне успешно применяется.
Цитировать
1.основная причина этого - в  разной природе данных.
Имена файлов - короткие - до 255 символов
сюда входят также путь до корневого каталога библиотеки, а это - величина переменная для каждого юзера
Ну Name Creator делает ещё более длинные имена файлов - чем мною предлагаемые - и ничего, хватает, видимо 255 символов.
Цитировать
2.кодировка-транслитерация. Вобчем, нет ни одного стандарта, где бы описывалась транслитерация ВСЕХ символов. Потому что сейчас транслитерация как таковая уже не очень актуальна. Так, ошметки старых технологий. Все новое и в юникоде прекрасно живет без всякой транслитерации. Т.е. здесь придется городить некий гибрид, трудоемкость создания которогону очччень большая, а смысл?
Смысл большой - ПРОСТОТА. Мне программно в тысячу раз проще работать на ASCII-коде - чем на Юникоде. И не везде Юникод-имена поддерживаются (Windows 98, например). Большинство книг в PDF и DjVu имеют названия на популярных языках - для которых предусмотрена транслитерация. Если же для каких-то символов не предусмотрена транслитерация - всё равно можно как-то выкрутиться. И Name Creator работает на ASCII-коде - и правильно делает. Я против Юникода. Это дело далёкого будущего - когда ASCII умрёт естественной смертью.
И Юникод не одинаково хорошо везде поддерживается, да и разный он (UTF8, UTF16, с BOM и без него, и т.п.). А сколько гемора бывает при переводе из Юникода во что-то иное? Нет, Юникод - ИМХО сложная и неподходящая сущность пока что, порождающая кучу проблем. Ничего, вполне перебьёмся кодами ASCII - с вполне достаточной точностью (для наших целей).
Цитировать
4.опыт. Работал много на почве создания база данных из имен файлов. Типа, занимался как раз той обратной задачей - извлекал метаданные. И не видел ни одной системы именования, чтобы она позволяла однозначно решить задачу. В лучшем случае будет потеря метаинформации, в худшем- обрезание и смешение разных типов.
Можно подробнее? Желательны какие-то примеры - а то голословно непонятно.
Я опираюсь на опыт работы программы Name Creator. Она давно и успешно работает - я лишь предлагаю её модернизировать.
Цитировать
ессно, если ИСБН есть. А на нет - и суда нет:) Тем более, что ИСБН не читаем, и будет дополнением к имени где есть нормальное название. Ну а нету ИСБН у книги - и не будет этого куска.
Да, я тоже так думаю. А если нет ISBN, но есть, скажем, УДК - то писать UDK ... (по желанию).
Цитировать
каталогизация - это совершенно другая задача. ПРичем уже во многих отношениях решенная - см. тот же хокм-либ. Такох прог еще с десяток найти можно. У всех у них основная проблема - где брать метаинформацию, все решают по разному, ну дык и пусть берут ее с фбд файлов. А курочить имена они до сих пор не научилсь. Так почему ты думаешь, что научатся в будущем?
Но я пока не вижу причин, почему бы нельзя было делать каталогизацию, "куроча имя файлов". Я пока не вижу притиворечия между 2 задачами "сделать говорящее имя файла" и "сделать автоматический разбор имени файла для автоматической каталогизации".
Цитировать
Так почему ты думаешь, что научатся в будущем?
А почему нет? Объясните, пожалуйста. Вот пример имени файла:

Avtor A. A., Vtoroj B.B., Tretij V.V.__Nazvanie_225s_RU_1995_Izdatelstvo_2izd_ISBN 0000000000_Q4.djvu

Смотрите - здесь решены сразу обе задачи.

Задача 1 (Человеко-информативное имя):
По имени файла видна (человеку - не скачивая с сайта книгу) вся основная информация о книге - кто автор, какое название, и т.п.

Задача 2 (Поддержка автоматической каталогизации):
Такое имя файла легко разбивается машинным способом на токены - Автор, Название, Год, Издание, и т.п. Это очень удобно для автоматической генерации HTML-списков имеющихся у юзера книг. Вот юзер, допустим, накачал с Интернета в произвольном порядке таких файлов, и свалил их все в одну папку. А потом запускает некий каталогизатор - и тот юзеру на полном автомате генерирует HTML-список книг - разбивая его на столбцы "Автор", "Название", и т.п. Причём попутно генерируются гиперлинки - кликнув на которые, можно будет открыть PDF или DjVu в просмотрщике.

Разве это не удобно и такой функционал будет лишним? Это же полностью автоматизирует каталогизацию накаченного из Сети (т.е. только PDF- и DjVu-книг).

Вы хотите сказать, что такая схема автоматической каталогизации будет зато негибкой (а слишком строго предопределённой) - и другим юзерам захочется как-то иначе каталогизировать - а потому, дескать, это "задача нерешаемая"?

Да, это негибкая схема каталогизации. Но a что может быть взамен? Да ничего - взамен может быть только вариант с полным отсутствием поддержки автоматической каталогизации. Но будет ли от этого лучше - если вообще отказаться от поддержки автоматической каталогизации? Думаю, нет. Пусть лучше будет хоть плохая - чем вообще никакая.
Цитировать
Главный резон - уже есть каталогизаторы, что понимают этот формат. Например, http://home-lib.net.
Это не довод. Ну и что, что "они уже есть"? А если там, к примеру, не то, что нам нужно? Хотя что там такое - я не знаю - попробую тот сайт почитать.
Цитировать
3.разделение полей в имени. Нормально это только тегами можно сделать, у тебя это токены, но они тоже занимают место, и это все - из тех же 255 символов. А если ты хочешь в имя запихнуть много полей, то у тебя получится, что от трети до половины длины имени уйдет на сами токены.
А с Name Creator всё делается сейчас ничуть не лучше. Там хоть не подчёркивания - так зато пробелы взамен (без пробелов нельзя - они для человеко-понятности нужны).
Цитировать
А если ты хочешь в имя запихнуть много полей, то у тебя получится,
А почему я должен этого хотеть? Мне это НЕ НАДО. Надо лишь довольно ограниченный стандартный набор токенов привести в имени - и ДОСТАТОЧНО. Ради чего ещё что-то пхать в имя файла? Не вижу смысла.
« Последнее редактирование: 16 БХЭвпСам 2010, 15:24:59 от monday2000 »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Вот ещё у меня раньше была мысль - помещать в имя файла книги некий токен, определяющий своего рода "код области знания", к которому относится данная книга. Это для повышения точности/удобства автоматической каталогизации. Тем более, что такой токен есть в Name Creator.

Но потом я от этой идеи отказался - слишком сложно. Практически-нереализуемо. А в Name Creator код области знания - условный, из таблицы кодов знания электронной библиотеки "Колхоз" (так что всем остальным юзерам от него нет проку).

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kv
Читаю страницу http://wiki.home-lib.net/index.php/%D0%A7%D1%82%D0%BE_%D1%82%D0%B0%D0%BA%D0%BE%D0%B5_FBD
Цитировать
Что такое FBD

FBD - это формат хранения описаний книг.

Файлы описаний используются для хранения библиографической информации об электронных версиях книг в форматах, не позволяющих вносить данную информацию в сами файлы. К таким форматам относятся TXT, DjVu, DOC/RTF и многие другие форматы, изначально не предназначенные для создания на их базе электронных книг.

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

По сути своей, файл в формате FBD является пустым докуметом в формате FB2 с заполненным описанием.

Файлы описаний должны иметь тоже имя, что и файлы книги и располагаться в одной с ними дирректории или архиве. К примеру, если электронная книга имеет имя "Book.pdf", то файл описаний - "Book.fbd"

Они могут содержать в себе такие выходные данные книга, как имя автора, название, серия, обложка, аннотация, данные об исходной книге, жанр и многое другое. Как уже говорилось ранее, самым большим преимуществом в использованини файлов описаний является возможность рабоать с книгами в форматах, отличных от FB2 в автоматическом режиме. Это позволит загружать его в онлайн-библиотеки, скачивать и добавлять в программы-каталогизаторы без дополнительного ввода пользователем информации о книге.
Здесь неточная информация: Формат DjVu уже позволяет осуществлять "хранение библиографической информации об электронных версиях книг" - т.е. другими словами, он поддерживает метаданные. Это раньше так было, что DjVu не поддерживал метаданные - но не теперь - теперь поддерживает.

Естественно, использование метаданных гораздо лучше, чем использование таких вот FBD-файлов.

И, скорее всего, вся та информация, что содержится в FBD-файлах, может быть записана в метаданных DjVu (PDF) файла. Точно не могу сказать - насколько велико совпадение - но наверняка довольно близко.

Кстати - файлы в форматах TXT и DOC я бы предложил автоматически преобразовывать в FB2. Благо, что и софт для этого есть (или реально сделать). FB2 во всех отношениях выигрышнее, чем TXT, DOC и даже HTML.
« Последнее редактирование: 16 БХЭвпСам 2010, 16:33:53 от monday2000 »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kv
Такая фича, как поддержка именем файла автоматической каталогизации, будет не лишней. Тогда можно будет разделять операцию генерации имён файлов и операцию генерации метаданных файлов. Допустим, один человек генерирует "говорящие" имена и загружает в Интернет полученные файлы (названные этими именами). А другой берёт и внедряет в них метаданные - автоматически генерируя их из имён файлов. Естественно, при этом заполнятся не все поля метаданных - а лишь некоторая часть (поскольку в имени файла будут только ключевые данные - в метаданных вообще гораздо больше инфы помещается).

Зачем нужна такая схема? (когда один заполняет имена файлов - а второй на их основе - метаданные) Затем, что у первого человека может не быть технической возможности внедрять DjVu и PDF-метаданные.

По поводу транслита: поскольку в имени файла всегда будет содержаться токен языка книги, то тогда уж всегда будет ясно, по какому стандарту производить обратную транслитерацию из транслита в конкретный язык. Думаю, практически для каждого языка существует что-то вроде ГОСТа (или ISO-стандарта), задающего взаимно-однозначное прямое и обратное транслитерирование.
Зато использование ASCII вместо Юникода даёт максимальную простоту программной работы с именами файлов.

В мире не найдётся компьютера, который не поддерживал бы ASCII - зато сколько угодно компьютеров, не поддерживающих Юникод. (в смысле "по факту" не поддерживающих, а не "вообще")
« Последнее редактирование: 16 БХЭвпСам 2010, 16:50:02 от monday2000 »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kv
Кажется, я понял суть Вашей критики.

Оказывается, каталогизация может быть разной - для домашней библиотеки - и для онлайн-библиотеки.

Для домашней каталогизации требования гораздо выше, чем для онлайн-библиотеки. Это видно хотя бы из рассмотрения http://home-lib.net/ .

Я же рассматриваю исключительно каталогизацию онлайн-библиотек. Поэтому-то и реально совместить воедино две противоречивые задачи - человеко-узнаваемость и поддержку автоматической каталогизации.

Так что задачи и опыт http://home-lib.net/ практически мало применимы для целей данного топика. Для онлайн-библиотеки достаточна лишь самая общая каталогизация. Самая "аскетичная", так сказать. Такую вполне можно утиснуть в предопределённый набор токенов в имени файла.

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kv
Мне пришла в голову такая мысль:

А знаете - мы вполне можем разработать не одну схему именования файлов - а несколько полностью независимых друг от друга таких схем! :o

Ведь у нас есть метаданные - и никто нам не мешает, взяв метаданные, из них автоматически (по определённому шаблону) генерировать имена файлов по самой понравившейся схеме (схеме именования)!

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

Какие-то иные схемы могут быть для иных случаев жизни.

kv

  • Новичок
  • *
  • Сообщений: 11
    • Просмотр профиля
    • E-mail
kv
Кажется, я понял суть Вашей критики.

Оказывается, каталогизация может быть разной - для домашней библиотеки - и для онлайн-библиотеки.

Для домашней каталогизации требования гораздо выше, чем для онлайн-библиотеки. Это видно хотя бы из рассмотрения http://home-lib.net/ .

Я же рассматриваю исключительно каталогизацию онлайн-библиотек. Поэтому-то и реально совместить воедино две противоречивые задачи - человеко-узнаваемость и поддержку автоматической каталогизации.

Так что задачи и опыт http://home-lib.net/ практически мало применимы для целей данного топика. Для онлайн-библиотеки достаточна лишь самая общая каталогизация. Самая "аскетичная", так сказать. Такую вполне можно утиснуть в предопределённый набор токенов в имени файла.
неправильно.
Потому как каталогизация он-лайн-библиотек - это ВСЕГДА файлы+база данных. И как именуется файл - здесь вообще по барабану. Например, в либгене файлы именуются по мд5 хешу. Даже без расширения. А хочет юзер скачать себе файл - ему выдается имя файла, сгенеренное "на лету" по полям базы. Так что для он-лайн либов нет проблемы обозвать файл, а есть проблема найти метаданные, чтоб засунуть их в базу.

Я так понял, что ты (сорри, привычка, предлагаю перейти) разрабатываешь эту задачу с целью генерации имен для НОВЫХ ОТСКАНЕННЫХ книг. Вот я и говорю - для них метаданные надо совать в 2 места - в сам файл, в служебное поле, а там можно поизвращаться как угодно, например, данные для которых есть поля, засунуть в поля, а те, что есть - в какое-то поле примечаний и туда уже токены и прочие вкусности. А заодно - фб2 - это вообще просто, это XML файл. Текм самым убиваются решаются 2 задачи
1.ДЛя он-лайн либов легко решается задача добывания метаданных
2.Для домашней либы легко решается задача подключения новой книги посредством каталогизаторов, поддерживающих фбд.

Ну а именование файла - это делается на основе шаблона в ини файле - кто как захотел - тот так и поименовал. Я не берусь предсказать предпочтения сканировщиков.

Касаемо опыта добывания инфы из имен файлов, то посмотри на траблы, что возникли при развертывании либгена.
1.Простое развертывание либы Колхоза на домашнем компе - сложная задача, которая уперлась как раз в 255 символов. В результате BookWarrior наваял инсталлятор в виде батников, который переделывал колхозные имена что файлы тупо можно было скопировать к себе н комп.
2.потом он сколько-то времени курочил колхозные имена файлов стоб добыть оттуда метаданные для базы данных.
3.потом я лично правил поля на предмет правильно разнесения инфы по полям, разных там сокращений, правильного порядка в ФИО и т.д.
4.после этого к базе либгена добавлено еще 220 тыс книг, и примерно для половины из них инфа берется из имен файлов.
5.в результате качество описания книг после 120 тыщи резко пошло вниз, потому как БГ добавляет книги быстрее чем народ правит поля в базе.

Ну а в качестве примера - вот тебе страница, попрактикуйся составлять имена а потом посмотри что получается.
http://free-books.dontexist.com/search?req=%D0%BC%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F+%D1%82%D0%B5%D0%BE%D1%80%D0%B8%D1%8F&nametype=orig