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

monday2000

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

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

В общем, я так думаю: постараюсь основной упор сделать на правильность заполнения юзером метаданных (в свежеотсканенных PDF и DjVu).
Цитировать
Ну а именование файла - это делается на основе шаблона в ини файле - кто как захотел - тот так и поименовал. Я не берусь предсказать предпочтения сканировщиков.
Я тоже так думаю - генерировать информативное имя файла из его метаданных по заданному шаблону (выбирая шаблон по своему вкусу). С одним уточнением: давайте один такой шаблон сделаем "шаблоном по умолчанию". Всё-таки как-то слишком уж необычно, если юзер будет выкладывать в Сеть файл с именем в виде md5. ;D Давайте уж лучше ему разработаем "шаблон по умолчанию" - с которого я и начал данный топик.

Правда, надо как-то решить проблему 255 символов. Буду думать и искать компромисс. Первое, что приходит на ум - задать ограничение длины имени файла - порядка 240-250 (от силы) символов. С расчётом хранения книг либо в первой папке в корне DVD, либо в папке, скажем "D:\1". Что-то в этом роде.
« Последнее редактирование: 16 БХЭвпСам 2010, 18:23:04 от monday2000 »

kv

  • Новичок
  • *
  • Сообщений: 11
    • Просмотр профиля
    • E-mail
kv
Очень интересно.

Короче говоря, по большому счёту мы приходим к той мысли, что самое главное - это правильно заполнить метаданные - а какое при этом будет имя файла - вообще не важно (главное, чтобы оно было не более 255 символов, включая путь). Я правильно понял главный вывод? :)
не совсем. надо добавить
2.чтоб имя содержало только символы, допустимые в большинстве файловых систем.
3.чтоб оно было "удобочитаемым" с точки зрения юзера. Причем здесь должна быть полная свобода понимания термина "удобочитаемость". Вон, например, для БВ допустимы только имена файлов=мд5, мне достаточно название-авторы-год-ИСБН.расширение и т.д. Т.е. поддержка шаблона для формирования имен.
Цитировать
Цитировать
Я так понял, что ты (сорри, привычка, предлагаю перейти) разрабатываешь эту задачу с целью генерации имен для НОВЫХ ОТСКАНЕННЫХ книг.
Да-да, именно так. Вот отсканировал человек у себя дома книгу - пускай он её "правильно" назовёт (как минимум) - и только потом заливает в Интернет.
ну дык тогда главное - дать человеку средство, облегчающий процесс "правильного называния". А это уже зависит от твоих программерских навыков, потому как придумать можно много. Например, если в книге есть ИСБН, то самое правильное - помочь челу вычленить его, а потом пусть прога сама слазит в базу ИСБН и выгребет оттуда все что там есть и предложит поместить это в поля метаданных. В либгене, кстати, такое есть - при добавлении и редактировании книги.
Цитировать
Цитировать
Вот я и говорю - для них метаданные надо совать в 2 места - в сам файл, в служебное поле, а там можно поизвращаться как угодно,
Я и предлагаю, что моя программа будет ОДНОВРЕМЕННО генерировать как инфоративное имя - так и метаданные - и будет эти метаданные записывать - внутрь самого файла.
внутрь - отлично. А сгенерить фбд что мешает? ПОтому как многие каталогизаторы не умеют лазать внутрь пдф или джву, но понимают фбд. Твоя ж задача - облегчить жизнь дальнейшим юзателям твои сканов? Вот и облегчи...
Цитировать
Цитировать
А заодно - фб2 - это вообще просто, это XML файл.
Вы имеете в виду "формат FBD"? Я надеюсь, что его можно будет полностью автоматически генерировать из PDF- и DjVu-метаданных (точно, правда, не знаю, так ли это - но скорее всего).
можно, но таких прог я пока не знаю. Может потому как не искал, но, думаю, что пока нету, потому как фбд- сравнительно новое новшество. ВОт и сделай такой генератор, думаю, будет полезно...
Цитировать
Цитировать
2.потом он сколько-то времени курочил колхозные имена файлов стоб добыть оттуда метаданные для базы данных.
Ага, ну вот видите - если бы уже тогда был в ходу такой стандарт, как я предлагаю, то тогда наполнение метаданных (хотя бы частичное) шло бы автоматом - путём парсинга имён файлов.
дык парсили колхозные имена - там есть достаточно четкая система. Name Creator - сам же говорил. Но вот достать оттуда чтоб однозначно - тяжко. Ну и названия и авторы там обрезаны иногда.
Цитировать
Цитировать
Ну а в качестве примера - вот тебе страница, попрактикуйся составлять имена а потом посмотри что получается.
Не пойму - что значит "попрактикуйся"? Зачем?
в смысле на основании метаданных что есть в базе, попробуй сделать имена по твоему алгоритму. И увидишь, что часть метаданных ты потеряешь. Ну а если не потеряешь - покажи, тебе памятник:)

Цитировать
В общем, я так думаю: постараюсь основной упор сделать на правильность заполнения юзером метаданных (в свежеотсканенных PDF и DjVu).
да, это правильно!
Цитировать
Цитировать
Ну а именование файла - это делается на основе шаблона в ини файле - кто как захотел - тот так и поименовал. Я не берусь предсказать предпочтения сканировщиков.
Я тоже так думаю - генерировать информативное имя файла из его метаданных по заданному шаблону (выбирая шаблон по своему вкусу). С одним уточнением: давайте один такой шаблон сделаем "шаблоном по умолчанию". Всё-таки как-то слишком уж необычно, если юзер будет выкладывать в Сеть файл с именем в виде md5. ;D Давайте уж лучше ему разработаем "шаблон по умолчанию" - с которого я и начал данный топик.
дык а в чем проблема - твоя прога поставляется с одним вариантом ини файла, где записан "твой" шаблон - это и есть по умолчанию. А кого не устраивает и кто поймет как делать другие - сделает себе свой.

Цитировать
Правда, надо как-то решить проблему 255 символов. Буду думать и искать компромисс. Первое, что приходит на ум - задать ограничение длины имени файла - порядка 240-250 (от силы) символов. С расчётом хранения книг либо в первой папке в корне DVD, либо в папке, скажем "D:\1". Что-то в этом роде.
ага, вот в колхозе так и сделали. В результате, собрать колхоз можно только в корне диска. Ну а сейчас когда диски можно монтировать куда угодно в дерево каталогов, ты юзерам подкладываешь свинью.
Вобчем, проблема 255 никак не решается. В принципе. Потому как еще раз - не надо путать имя файла и метаданные. Вот не путай, и у тебя такой проблемы не будет.

Я уже молчу о том, что в либгене есть больше тыщи книг, у которых длина имена книги > 300 символов. Ты их как обрезать предлагаешь - по слову или прямо в середине слова?

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kv
Цитировать
2.чтоб имя содержало только символы, допустимые в большинстве файловых систем.
То есть ASCII.
Цитировать
Например, если в книге есть ИСБН, то самое правильное - помочь челу вычленить его, а потом пусть прога сама слазит в базу ИСБН и выгребет оттуда все что там есть и предложит поместить это в поля метаданных.
Ну, на такое я пока вообще не замахиваюсь. Может быть, в отдалённом будущем.
Цитировать
3.чтоб оно было "удобочитаемым" с точки зрения юзера. Причем здесь должна быть полная свобода понимания термина "удобочитаемость".
Да, я полностью согласен с обоими положениями.
Цитировать
внутрь - отлично. А сгенерить фбд что мешает? ПОтому как многие каталогизаторы не умеют лазать внутрь пдф или джву, но понимают фбд.
А зачем именно мне генерить FBD? Пусть это делает не лично сам единичный юзер - а автоматическая программа в онлайн-библиотеке - когда юзер уже загрузит туда свою книгу. Или же домашний каталогизатор у юзера.
Цитировать
можно, но таких прог я пока не знаю. Может потому как не искал, но, думаю, что пока нету, потому как фбд- сравнительно новое новшество. ВОт и сделай такой генератор, думаю, будет полезно...
Я не буду (это уже чрезмерно будет лично для меня) - но кто-то иной - вполне сможет сделать.
Строго говоря, генерировать FBD вообще не нужно. Зачем - когда уже есть метаданные в DjVu и PDF. Грубо говоря, FBD и метаданные в DjVu и PDF - это одно и то же. FBD может оказаться выгоднее лишь в бОльшей скорости доступа туда (но не факт).
Цитировать
дык парсили колхозные имена - там есть достаточно четкая система. Name Creator - сам же говорил. Но вот достать оттуда чтоб однозначно - тяжко. Ну и названия и авторы там обрезаны иногда.
Колхозные имена так просто не пропарсишь. Я же предлагаю такой шаблон говорящего имени, который будет парситься полностью автоматически.
Цитировать
в смысле на основании метаданных что есть в базе, попробуй сделать имена по твоему алгоритму. И увидишь, что часть метаданных ты потеряешь.
Да, потеряю. Иначе не получится. В имени файла могут уместиться только самые ключевые метаданные.
Цитировать
дык а в чем проблема - твоя прога поставляется с одним вариантом ини файла, где записан "твой" шаблон - это и есть по умолчанию. А кого не устраивает и кто поймет как делать другие - сделает себе свой.
Да, всё так и будет.
Цитировать
ага, вот в колхозе так и сделали. В результате, собрать колхоз можно только в корне диска. Ну а сейчас когда диски можно монтировать куда угодно в дерево каталогов, ты юзерам подкладываешь свинью.
Вобчем, проблема 255 никак не решается. В принципе.
Да, я согласен с тем, что "проблема 255 никак не решается в принципе". Всё, что тут можно сделать - ввести жёсткое ограничение на длину имени файла порядка 245 символов.
Цитировать
Я уже молчу о том, что в либгене есть больше тыщи книг, у которых длина имена книги > 300 символов. Ты их как обрезать предлагаешь - по слову или прямо в середине слова?
Даже не знаю. А как лучше? Но обрезать-то прийдётся по-любому. Но, надеюсь, в любом случае, 245 символов хватит, чтобы сохранить человеко-понятность имени файла - а точные данные о книге всё равно будут храниться в метаданных.
« Последнее редактирование: 17 БХЭвпСам 2010, 09:36:56 от monday2000 »

monday2000

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

Если что и было бы желательно добавить, так это количество страниц книги.

kv

  • Новичок
  • *
  • Сообщений: 11
    • Просмотр профиля
    • E-mail
Цитировать
внутрь - отлично. А сгенерить фбд что мешает? ПОтому как многие каталогизаторы не умеют лазать внутрь пдф или джву, но понимают фбд.
А зачем именно мне генерить FBD? Пусть это делает не лично сам единичный юзер - а автоматическая программа в онлайн-библиотеке - когда юзер уже загрузит туда свою книгу. Или же домашний каталогизатор у юзера.
Цитировать
можно, но таких прог я пока не знаю. Может потому как не искал, но, думаю, что пока нету, потому как фбд- сравнительно новое новшество. ВОт и сделай такой генератор, думаю, будет полезно...
Я не буду (это уже чрезмерно будет лично для меня) - но кто-то иной - вполне сможет сделать.
Строго говоря, генерировать FBD вообще не нужно. Зачем - когда уже есть метаданные в DjVu и PDF. Грубо говоря, FBD и метаданные в DjVu и PDF - это одно и то же. FBD может оказаться выгоднее лишь в бОльшей скорости доступа туда (но не факт).
хозяин-барин. Ессно, решать что делать - тебе. Но имей в виду, если этого не сделаешь, то твоя прога будет востребована лично тобой и еще может десятком сканировщиков, а твои файлы встроить в либу, что домашнюю, что серверную, будет так же сложно как и сейчас. Потому как кому-то придется писать для этого софт. Не факт что кто-то это сделает. А если сделаешь - то ты решишь не только задачу именования, но и задачу дальнейшего распространения твоих сканов. Надо это тебе или нет - решать тебе.
Цитировать
Цитировать
дык парсили колхозные имена - там есть достаточно четкая система. Name Creator - сам же говорил. Но вот достать оттуда чтоб однозначно - тяжко. Ну и названия и авторы там обрезаны иногда.
Колхозные имена так просто не пропарсишь. Я же предлагаю такой шаблон говорящего имени, который будет парситься полностью автоматически.
это называется "за рыбу гроши". Вроде как уже согласились что метаданные надо доставать из метаданных дву и пдф, я еще и за фбд ратую. А ты снова - парсить имена. Еще раз. Если есть метаданные полные, парсить имена - зло. И не надо делать ничего, что бы облегчило это зло. Надо приучать народ пользоваться правильными данными. Потому я и говорю про фбд - оттуда данные достать проще, чем из пдф и джву. Да и вообще - это текстовый формат, там даже блокнот поможет.
Цитировать
Цитировать
в смысле на основании метаданных что есть в базе, попробуй сделать имена по твоему алгоритму. И увидишь, что часть метаданных ты потеряешь.
Да, потеряю. Иначе не получится. В имени файла могут уместиться только самые ключевые метаданные.
Когда метаданные попадут в имя файла, они ПЕРЕСТАНУТ быть метаданными. Теперь это просто - ИМЯ ФАЙЛА - и ничего больше.
Цитировать
Цитировать
ага, вот в колхозе так и сделали. В результате, собрать колхоз можно только в корне диска. Ну а сейчас когда диски можно монтировать куда угодно в дерево каталогов, ты юзерам подкладываешь свинью.
Вобчем, проблема 255 никак не решается. В принципе.
Да, я согласен с тем, что "проблема 255 никак не решается в принципе". Всё, что тут можно сделать - ввести жёсткое ограничение на длину имени файла порядка 245 символов.
НЕТ. не надо из имен файлов пытаться достать метаданные.
Цитировать
Цитировать
Я уже молчу о том, что в либгене есть больше тыщи книг, у которых длина имена книги > 300 символов. Ты их как обрезать предлагаешь - по слову или прямо в середине слова?
Даже не знаю. А как лучше? Но обрезать-то прийдётся по-любому. Но, надеюсь, в любом случае, 245 символов хватит, чтобы сохранить человеко-понятность имени файла - а точные данные о книге всё равно будут храниться в метаданных.
Чтоб сохранить человеко-понятность, обрезать можно как угодно, да и вообще задача формирования имени очень сильно упрощается. Например, при транслитерации разные умляуты можно менять на соств.символы без диакритики - если есть такая таблица,  а не нашлась - ну и фиг с ним, подчеркивание и все. "Понятности" это не сильно навредит, но - насколько проще! А информацию ты не потерял - потому как все записано в файл метаданных. Но теперь нужны средства работы с метаданными. Вобчем - доставать из имени - это КАЖУЩАЯСЯ простота, которая порождает хаос. А вот для работы с настоящими метаданными надо ПО. Вот я и призываю к созданию такого ПО.
« Последнее редактирование: 17 БХЭвпСам 2010, 11:10:43 от kv »

monday2000

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

Метаданные формата DjVu - это в точности метаданные формата PDF. Т.е., когда владельцы прав на формат DjVu (Caminova.net) решали, а какие бы метаданные ввести в употребление в формат DjVu, какого именно формата - то решили просто без затей взять метаданные формата PDF и внедрить их в DjVu.
Цитировать
Еще раз. Если есть метаданные полные, парсить имена - зло.
Да, я прекрасно понимаю, что "зло". Но всё-таки бывают редкие случаи в жизни, когда по какой-то причине нам надо пропарсить имя файла - и забить извлечённой оттуда иинформацией поля метаданных.

Вот именно ради этой редкой (но тем не менее, реально существующей) потребности я и планирую сделать некий стандарт человеко-узнаваемого имени по-умолчанию - могущий быть полностью автоматически пропарсен в метаданные (естественно, частично).
Цитировать
Надо приучать народ пользоваться правильными данными.
Ну надо, конечно, только вот некоторым хоть кол на голове теши - им всё будет невдомёк, они будут всё говорить "а что такое метаданные?" :)
Цитировать
Потому я и говорю про фбд - оттуда данные достать проще, чем из пдф и джву.
Просто пусть кто-нибудь (не обещаю, что я) сделает автоматический конвертор "метаданные PDF DjVu" -> FBD.
Цитировать
Когда метаданные попадут в имя файла, они ПЕРЕСТАНУТ быть метаданными. Теперь это просто - ИМЯ ФАЙЛА - и ничего больше.
Совершенно верно, я прекрасно это понимаю.
Цитировать
НЕТ. не надо из имен файлов пытаться достать метаданные.
Но, как я говорил чуток выше - парсение имени в метаданные - это крайне редкая необходимость (даже скажем, я это рассматриваю как чрезвычайную меру - когда просто нет иного выхода). В норме в PDF и в DjVu должны будут наличествовать метаданные - а на данные из имени файла тогда можно будет вообще никак не опираться.
Цитировать
"Понятности" это не сильно навредит, но - насколько проще! А информацию ты не потерял - потому как все записано в файл метаданных.
Вот именно, я точно так же тоже думаю.
Цитировать
Вобчем - доставать из имени - это КАЖУЩАЯСЯ простота, которая порождает хаос.
Да, я превосходно это понимаю. Как я написал выше, парсение имени в метаданные будет нужно исключительно как чрезвычайная задача (когда по какой-то причине отсутствуют метаданные).
Пусть изначально юзер помещает в Интернет файл, названный как раз таким именем, которое может быть автоматом (частично) пропарсено в метаданные. Потому что - а вдруг по какой-то причине юзер затруднится одновременно ещё и метаданные засунуть в выкладываемый впервые в Сеть PDF или DjVu-файл.

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

Мне кажется, что всё это будет не лишним.
Цитировать
А вот для работы с настоящими метаданными надо ПО. Вот я и призываю к созданию такого ПО.
Да, я теперь займусь именно этим. Ведь та программа, которую я планирую, она будет ОДНОВРЕМЕННО генерировать человеко-понятое имя (и тут же его присваивать файлу PDF или DjVu) и генерировать метаданные (и тут же их вставлять - в PDF либо в DjVu).

Но освоение программной работы с PDF-метаданными - это долгая песня - потребуется читать и вникать в спецификацию формата PDF и XMP.

Вот описание XMP: http://en.wikipedia.org/wiki/Extensible_Metadata_Platform
У XMP своя отдельная спецификация - выложена у Адобов на сайте:
http://www.adobe.com/devnet/xmp/

Плюс ещё и метаданные в формате "PDF DocInfo". C ними тоже надо разбираться ещё (это где-то внутри спецификации формата PDF).

Кстати - а почему бы формату FB2 не принять к использованию такие же метаданные, как и в PDF и DjVu - PDF DocInfo и XMP? Вот было бы здорово - было бы такое единообразие. Врочем, это необязательно.
« Последнее редактирование: 17 БХЭвпСам 2010, 11:54:00 от monday2000 »

kv

  • Новичок
  • *
  • Сообщений: 11
    • Просмотр профиля
    • E-mail
Цитировать
Еще раз. Если есть метаданные полные, парсить имена - зло.
Да, я прекрасно понимаю, что "зло". Но всё-таки бывают редкие случаи в жизни, когда по какой-то причине нам надо пропарсить имя файла - и забить извлечённой оттуда иинформацией поля метаданных.

Вот именно ради этой редкой (но тем не менее, реально существующей) потребности я и планирую сделать некий стандарт человеко-узнаваемого имени по-умолчанию - могущий быть полностью автоматически пропарсен в метаданные (естественно, частично).
нельзя быть чуть-чуть беременной. Если прога будет позволять создавать файлы БЕЗ метаинформации, то все будут именно так и делать. Потому как проще это, меньше работы, а человек всегда ищет легкие пути:)

НУ а парсить имена - без токенов это сделать нельзя. А с токенами - у тебя в имя файла влезет еще меньше метаданных, чем в колхозе. Правильную транслитерацию тоже сделать невозможно. Вобчем, твоя программа будет еще одним источником хаоса.
Цитировать
Цитировать
Надо приучать народ пользоваться правильными данными.
Ну надо, конечно, только вот некоторым хоть кол на голове теши - им всё будет невдомёк, они будут всё говорить "а что такое метаданные?" :)
зачем кому-то что-то говорить. Все проще. Есть поля - название, авторы и т.д - ну как в метаданных пдф, и до тех пор, пока минимальный набор из них, тот, что можно узнать из книги, не заполнишь - файл дразнится по мд5 хешу. Вот и весь кол. Ессно, возможны и друuие варианты.
Цитировать
Цитировать
Вобчем - доставать из имени - это КАЖУЩАЯСЯ простота, которая порождает хаос.
Да, я превосходно это понимаю. Как я написал выше, парсение имени в метаданные будет нужно исключительно как чрезвычайная задача (когда по какой-то причине отсутствуют метаданные).
Пусть изначально юзер помещает в Интернет файл, названный как раз таким именем, которое может быть автоматом (частично) пропарсено в метаданные. Потому что - а вдруг по какой-то причине юзер затруднится одновременно ещё и метаданные засунуть в выкладываемый впервые в Сеть PDF или DjVu-файл.

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

Мне кажется, что всё это будет не лишним.
благими намерениями вымощена дорога...

Счас в либгене несколько тыщ. книг где в базе данных числится в поле Название нечто типа VTA0075rtk.pdf. У БГ принцип - добавить в либген, а потом видно будет. В результате, эти файлы через интерфейс найти нельзя, потому как никому не прийдет в голову делать запрос c буковсками. Вот тебе пример мануалов по панасоникам
http://free-books.dontexist.com/search?req=-DS&nametype=orig

Вобчем, повбивав бы:)
Цитировать
Цитировать
А вот для работы с настоящими метаданными надо ПО. Вот я и призываю к созданию такого ПО.
Да, я теперь займусь именно этим. Ведь та программа, которую я планирую, она будет ОДНОВРЕМЕННО генерировать человеко-понятое имя (и тут же его присваивать файлу PDF или DjVu) и генерировать метаданные (и тут же их вставлять - в PDF либо в DjVu).

Но освоение программной работы с PDF-метаданными - это долгая песня - потребуется читать и вникать в спецификацию формата PDF и XMP.
именно поэтому я завел разговор про фбд. С ним точно будет быстрее.

Да и с метаданными пдф тоже не все так просто. Например, ты уверен что туда должны вставляться данные по содержимому файла а не по самому файлу? Вот, например, что там должно быть, если в файле - сборник выдранных откуда-то статей?

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kv
Цитировать
нельзя быть чуть-чуть беременной. Если прога будет позволять создавать файлы БЕЗ метаинформации, то все будут именно так и делать. Потому как проще это, меньше работы, а человек всегда ищет легкие пути:)
Ну, если человек не захочет создавать метаданные - то я его не заставлю. :) А в моей программе одни и те же токены будут сразу идти как в имя файла, так и в метаданные. А потом надо будет просто ещё дописать остающиеся метаданные.
Цитировать
А с токенами - у тебя в имя файла влезет еще меньше метаданных, чем в колхозе.
Неправда. Ровно столько же и влезет - просто кое-где колхозные пробелы заменятся на подчёркивания и всё - так что без разницы. И даже больше влезет (за счёт того, что вместо указывания конкретных признаков качества будет указываться 5-балльный квалификатор качества - который гораздо короче по длине). И у меня не будет дурацких колхозных круглых скобок (где 2-я скобка - это чистая потеря длины имени на 1 символ).
Цитировать
Правильную транслитерацию тоже сделать невозможно.
Для наиболее распространённых языков - возможно. А как же тогда по-Вашему существует NameCreator - и почему-то многие им реально пользуются? Правда, многих он и отпугивает чрезмерной замороченностью. Я-то как раз предлагаю куда как более простую систему именования файлов.

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

Но я думаю, что для большинства рунетовцев наиболее актуальны только русский и английский языки. Посмотрите на любую большую онлайн-библиотеку PDF-DjVu. Все остальные языки буду добавлять в программу индивидуально - по мере необходимости (в смысле, буду добавлять таблицу транслитерирования для конкретного языка - как это сделано в NameCreator).
Цитировать
Вобчем, твоя программа будет еще одним источником хаоса.
Забавно. Но NameCreator - явно устарел. Так что его по-любому надо менять на что-то новое. Мой стандарт будет предназначен для простых смертных - не желающих особо заморачиваться. Вот NameCreator - тот слишком сильно заточен именно под Колхоз, так неправильно, это многих отпугивает (от NameCreator).
Цитировать
благими намерениями вымощена дорога...
А что Вы можете предложить? Не делать в имени поддержку авто-парсинга? Я считаю - делать, поскольку это совершенно несложно сделать - а выгоды налицо.
Цитировать
Счас в либгене несколько тыщ. книг где в базе данных числится в поле Название нечто типа VTA0075rtk.pdf.
Так забейте руками - в чём проблема? Времени нет? Да ну на это всегда время можно найти - каждый день перед сном по 20 минут тратить - через месяц всё и забьёте. Научитесь привлекать добровольцев-упорядочивателей библиотеки - да, это сложно, но всё-таки не абсолютно нереально.
Вон у SpaceLib есть проги, вытаскивающие из OCR-слоя тексты из книг, с большой долей вероятности имеющие библиографическую информацию о книге.
Цитировать
Вот, например, что там должно быть, если в файле - сборник выдранных откуда-то статей?
А что сочтёте нужным - то и пишите. Если контент PDF или DjVu файла имеет официальное библиографическое название - используйте его. Если не имеет - придумайте своё название.
« Последнее редактирование: 17 БХЭвпСам 2010, 14:29:49 от monday2000 »

kv

  • Новичок
  • *
  • Сообщений: 11
    • Просмотр профиля
    • E-mail
kv
Цитировать
нельзя быть чуть-чуть беременной. Если прога будет позволять создавать файлы БЕЗ метаинформации, то все будут именно так и делать. Потому как проще это, меньше работы, а человек всегда ищет легкие пути:)
Ну, если человек не захочет создавать метаданные - то я его не заставлю. :) А в моей программе одни и те же токены будут сразу идти как в имя файла, так и в метаданные. А потом надо будет просто ещё дописать остающиеся метаданные.
я написал один вариант как можно заставить. Тогда работать с именем надо в таком порядке - сначала вводятся метаданные, потом по шаблону будет автоматом построено имя. Нет метаданных - нет имени.
Цитировать
Цитировать
А с токенами - у тебя в имя файла влезет еще меньше метаданных, чем в колхозе.
Неправда. Ровно столько же и влезет - просто кое-где колхозные пробелы заменятся на подчёркивания и всё - так что без разницы. И даже больше влезет (за счёт того, что вместо указывания конкретных признаков качества будет указываться 5-балльный квалификатор качества - который гораздо короче по длине). И у меня не будет дурацких колхозных круглых скобок (где 2-я скобка - это чистая потеря длины имени на 1 символ).
Цитировать
Правильную транслитерацию тоже сделать невозможно.
Для наиболее распространённых языков - возможно. А как же тогда по-Вашему существует NameCreator - и почему-то многие им реально пользуются? Правда, многих он и отпугивает чрезмерной замороченностью. Я-то как раз предлагаю куда как более простую систему именования файлов.

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

Самое смешное -  в моем подходе до финиша доплыть быстрее, потому как задача гораздо проще. Никаких заморочек с транслитерацией, длиной, приданием "смысла" токенам и оптимизацией состава. И исключений НЕТ. Но да, надо сменить парадигму - типа, начать работать с метаданными, а не с именем файла. Знаю, это непросто:)

Цитировать
Цитировать
Вобчем, твоя программа будет еще одним источником хаоса.
Забавно. Но NameCreator - явно устарел. Так что его по-любому надо менять на что-то новое.
ага, на новый генератор хаоса:)
Цитировать
Цитировать
благими намерениями вымощена дорога...
А что Вы можете предложить? Не делать в имени поддержку авто-парсинга? Я считаю - делать, поскольку это совершенно несложно сделать - а выгоды налицо.
я написал - выгоды и простота - КАЖУЩИЕСЯ. Написал причины. Имеешь свое мнение - докажи. Хотя бы на примерах.

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
kv
Цитировать
Но да, надо сменить парадигму - типа, начать работать с метаданными, а не с именем файла. Знаю, это непросто:)
Это всё, конечно, понятно - но почему Вы упорно не желаете рассматривать тот случай, когда юзер не захочет формировать метаданные - а вот информативное имя - как раз захочет? Что тогда прикажете делать? Пример: реализация на Веб-сервере функционала программы NameCreator. А попробуйте-ка на сервере реализовать программную работу с PDF и DjVu-метаданными. Это только я в своей программе волен делать всё, что захочу. А поскольку речь идёт о разработке стандарта именования - то ещё неизвестно, как другие люди в своих программах этот стандарт реализуют.
Цитировать
я написал - выгоды и простота - КАЖУЩИЕСЯ. Написал причины. Имеешь свое мнение - докажи. Хотя бы на примерах.
Вот Вам и доказательство - случай, когда человек может и хочет работать с именами файлов - но в упор не хочет и не может работать с метаданными.
Цитировать
я написал один вариант как можно заставить. Тогда работать с именем надо в таком порядке - сначала вводятся метаданные, потом по шаблону будет автоматом построено имя. Нет метаданных - нет имени.
Думаю, что это на деле приведёт к игнорированию подобной программы. А если человек не знает, как заполнить хотя бы одно поле метаданных? Силой Вы юзера не заставите.
Цитировать
Подожди, а ты примеры делал? Сколько у тебя влезло?
Ещё не успел. Но это пока не важно. Потому что, чтобы там у меня ни вышло - а выбора всё равно нет - имя файла обязано быть первоначально человеко-понятным - а не в виде md5. А раз уж оно обязано быть человеко-понятным - тогда уж пускай одновременно оно будет с поддержкой автопарсинга в метаданные - потому что иначе было бы просто глупо не воспользоваться такой возможностью.
Цитировать
Дело колхоза живуче.
А как Вы думаете, почему? Потому что так правильно. Ещё раз повторюсь - имя файла обязано быть первоначально человеко-понятным. Можете принять это как аксиому. А вот внутри либгена - пусть имя хранится хоть в виде md5.
Цитировать
И исключений НЕТ. Но да, надо сменить парадигму - типа, начать работать с метаданными, а не с именем файла. Знаю, это непросто:)
А что же тогда юзеру писать в имени файла, когда он свою книгу впервые выкладывает в Сеть? Предлагаете ему писать имя файла в виде md5? :)
Цитировать
Самое смешное -  в моем подходе до финиша доплыть быстрее, потому как задача гораздо проще. Никаких заморочек с транслитерацией, длиной, приданием "смысла" токенам и оптимизацией состава.
Ну хорошо - вот я отсканировал книгу в DjVu. Сам. Затем заполнил в ней метаданные - всё, как Вы хотите. Ну а имя - какое по-Вашему имя файла мне теперь задать, перед тем как выкладывать в Интернет? В виде md5? :)
« Последнее редактирование: 17 БХЭвпСам 2010, 15:52:19 от monday2000 »

kv

  • Новичок
  • *
  • Сообщений: 11
    • Просмотр профиля
    • E-mail
kv
Цитировать
Но да, надо сменить парадигму - типа, начать работать с метаданными, а не с именем файла. Знаю, это непросто:)
Это всё, конечно, понятно - но почему Вы упорно не желаете рассматривать тот случай, когда юзер не захочет формировать метаданные - а вот информативное имя - как раз захочет? Что тогда прикажете делать? Пример: реализация на Веб-сервере функционала программы NameCreator. А попробуйте-ка на сервере реализовать программную работу с PDF и DjVu-метаданными. Это только я в своей программе волен делать всё, что захочу. А поскольку речь идёт о разработке стандарта именования - то ещё неизвестно, как другие люди в своих программах этот стандарт реализуют.
потому что я - последователен. И предложил и отстаиваю одну идею на протяжении всего треда. А не шарахаюсь со стороны в сторону.Типа, да, зло - а потом аксиома прямо противоположного плана. И я помню о первоначальной задаче - программа для сканировщика. О каком Веб-сервере ты говоришь? Ты что, собираешься через броузер сканить книжки? Или это мордв некой базы данных, куда надо будет заносить отсканенные книги? Ты уж определись, а о сферическом коне в вакууме в виде некоего "стандарта именования" говорить смысла нет, потому как стандарт - это совсем другое. Здесь сначала надо изучить что такое RFC и с чем его едят.

Ну и, если это программа для сканировщика, то где ты видел сканирощика, что не знает, что такое название книги или автор? А если совсем молодой, то пару раз заполнит, а там, глядишь и издательство и ИСБН научится находить:)

Ну а работать с пдф и джву - это ж ты собрался, я могу максимум или в фбд поковыряться или прогой Спейслиба воспользоваться:)

Доказательво - соображения общего плана доказательсвом быть не могут. И именно для этого нужны примеры. Если ты отбрасывавешь идею экспериментальной проверки теории, то кто ж тебе доктор...

Хотя, оно все понятно - дальше ты пишешь - чтоб не получилось - не важно. Снова классика - если факты не устраивают, значит факты отбрасываем. Твоя аксиома это только подтверждает. Т.е. ты для себя уже все решил, и теперь тред перешел в стадию банального стеба, типа
Цитировать
Ну хорошо - вот я отсканировал книгу в DjVu. Сам. Затем заполнил в ней метаданные - всё, как Вы хотите. Ну а имя - какое по-Вашему имя файла мне теперь задать, перед тем как выкладывать в Интернет? В виде md5? :)
ты хоть читал, что я писал? Еще раз. Если заполнены метаданные, имя сгенерируется автоматически по заданному шаблону. Задал, что там будет идти автор-название-издательство-год - так и будет. НО, при этом, в дальнейшем, парсить имя будет не нужно - потому как метаданные уже БУДУТ СОЗДАНЫ. Их надо будет только достать. Вот откуда - я говорю что проще из фб2 - наряду с пдф и джву. Значит надо туда и записать.

monday2000

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

Соответственно, если кто-то на своём веб-сервере реализует программно мой стандарт именования файлов - то где гарантия, что этот человек захочет одновременно там же (в той же программе) сделать внедрение метаданных?
Цитировать
Здесь сначала надо изучить что такое RFC и с чем его едят.
Я имею в виду, разумеется, самодельный стандарт - упрощённого образца.
Цитировать
Доказательво - соображения общего плана доказательсвом быть не могут.
Да ну что за ерунда - могут конечно же. Для человеко-понятности 245 символов всегда за глаза хватит в имени файла.
Цитировать
Еще раз. Если заполнены метаданные, имя сгенерируется автоматически по заданному шаблону. Задал, что там будет идти автор-название-издательство-год - так и будет. НО, при этом, в дальнейшем, парсить имя будет не нужно - потому как метаданные уже БУДУТ СОЗДАНЫ. Их надо будет только достать.
Да я со всем этим не спорю. Ну, а если НЕ будут заданы метаданные - что тогда-то делать? Все Ваши рассуждения хороши, только если метаданные есть. А если их нет - но зато есть хотя бы имя файла, могущее быть авто-пропарсено в часть метаданных - то это какой-никакой - но выход. А иначе прийдётся забивать руками метаданные (ну или вытаскивать из OCR-слоя - но это слишком ручной труд).

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

Короче говоря, я представляю себе всё это практически вот как:

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

Далее, например, библиотека Homelab просматривает этот книжно-новостной сайт и выкачивает себе все новые книги. Допустим, Homelab забирает себе этот DjVu, и видит: "ага, метаданных почему-то нет. Зато есть такое имя файла, которое можно пропарсить в метаданные - ну хотя бы частично. Что ж, хорошо. Парсим имя файла и заполняем частично метаданные." И всё - все дальнейшие возможные сценарии уже сводятся к Вашим вариантам (с опорой на метаданные). То есть после заполнения метаданных можно смело как угодно менять первоначальное имя файла - и это будет уже не страшно.

Разве плохо придумано?

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

А концепцию можно назвать как "обязательность первичного инфоимени". Сформулировать её можно так:

Все PDF и DjVu-файлы, впервые попадающие в Сеть, обязаны иметь инфоимя.

А вот будут ли все такие PDF и DjVu-файлы, впервые попадающие в Сеть, ОДНОВРЕМЕННО с инфоименем иметь ещё и метаданные (как ВЫ того хотите) - ещё не факт. По разным причинам (технические проблемы и человеческий фактор) такие файлы могут и не иметь метаданных. А вот инфоимя сгенерировать - можно будет даже и вручную накрайняк - глядя на описание стандарта инфоимени (которое я опубликую на своём сайте). Может, у человека не окажется под рукой программы - генератора инфоимени и метаданных - а PDF или DjVu-книгу надо строчно выложить.

Второй постулат я предлагаю сформулировать так:

"Запрет потери данных инфоимени"

Если PDF или DjVu-файл уже лежит в Сети и у него нет метаданных - запрещается менять его инфоимя до заполнения метаданных. (в смысле до автоматического частичного заполнения метаданных путём парсинга инфоимени)
« Последнее редактирование: 17 БХЭвпСам 2010, 19:48:25 от monday2000 »

kv

  • Новичок
  • *
  • Сообщений: 11
    • Просмотр профиля
    • E-mail
kv
Цитировать
О каком Веб-сервере ты говоришь?
Я имею в виду следующее: в первую очередь я намерен создать стандарт человеко-понятного имени.
отступление. Давай посмотрим как это было у других.
Одни хотели создать стандарт, и придумали семиуровневую модель и сеть Х.25. Теперь семиуровневую модель рассказывают на одной лекции а Х.25 можно увидеть в музее.

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

А вся разница - кто к чему стремился тогда, давно.

Цитировать
Который (стандарт) далее реализую в своей программе. Но - этот же самый стандарт сможет использовать любой другой человек, в смысле, любой другой человек сможет написать свою программу, где (также как я) программно воплотит данный стандарт. Например, на Веб-сервере. А вот зачем на Веб-сервере может понадобиться делать подобное - я не знаю. Но вот с NameCreator был такой случай - когда на PHP сделали на веб-сервере программу, которая делала то же самое, что делает NameCreator.

Соответственно, если кто-то на своём веб-сервере реализует программно мой стандарт именования файлов - то где гарантия, что этот человек захочет одновременно там же (в той же программе) сделать внедрение метаданных?
поясни мне, что на веб-сервере будет далать сканировщик. Вот ты, например. без воплощения, а как юзер.
Цитировать
Цитировать
Здесь сначала надо изучить что такое RFC и с чем его едят.
Я имею в виду, разумеется, самодельный стандарт - упрощённого образца.
что это такое. Приведи пример.
Цитировать
Цитировать
Доказательво - соображения общего плана доказательсвом быть не могут.
Да ну что за ерунда - могут конечно же. Для человеко-понятности 245 символов всегда за глаза хватит в имени файла.
еще раз. Проблемы "человеко-понятности" НЕТ. Есть проблема извлечения метаданных из строки в 254 символа. Потому как метаданные занимают БОЛЬШЕ. И из строки в 254 символа извлечь метаданные в 1000 символов НЕЛЬЗЯ.

Цитировать
Цитировать
Еще раз. Если заполнены метаданные, имя сгенерируется автоматически по заданному шаблону. Задал, что там будет идти автор-название-издательство-год - так и будет. НО, при этом, в дальнейшем, парсить имя будет не нужно - потому как метаданные уже БУДУТ СОЗДАНЫ. Их надо будет только достать.
Да я со всем этим не спорю. Ну, а если НЕ будут заданы метаданные - что тогда-то делать? Все Ваши рассуждения хороши, только если метаданные есть.
Приведи мне практическую ситуацию из опыта сканировщика, который только что отсканил книгу и у него НЕТ метаданных. Я представить могу только единственный вариант - он НЕ ХОЧЕТ заполнить метаданные (ессно, я предполагаю, что он работает с прогой, которая позволяет задать метаданные - т.е. с твоей будущей прогой). Итак, ответь на вопрос - почему ты, как сканировщик, не хочешьт заполнить метаданные. Ты ж на сканирование потратил от 1 до много часов, заполнить метаданные - несколько минут. В чем дело?

Итак, кто НЕ ХОЧЕТ - пусть пользуется NameCreator. Но твоя прога будет же лучше. Ведь правда? Вот и пусть платой за дополнительные удобства будет заполнение метаинформации.

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

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

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

Короче говоря, я представляю себе всё это практически вот как:

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

Далее, например, библиотека Homelab просматривает этот книжно-новостной сайт и выкачивает себе все новые книги. Допустим, Homelab забирает себе этот DjVu, и видит: "ага, метаданных почему-то нет. Зато есть такое имя файла, которое можно пропарсить в метаданные - ну хотя бы частично. Что ж, хорошо. Парсим имя файла и заполняем частично метаданные." И всё - все дальнейшие возможные сценарии уже сводятся к Вашим вариантам (с опорой на метаданные). То есть после заполнения метаданных можно смело как угодно менять первоначальное имя файла - и это будет уже не страшно.

Разве плохо придумано?
Плохо. Потому как ты игнорируешь факты. А именно - нельзя запихать метаданные в имя файла. А вот как я говорю - можно. Потому как ничего запихивать не надо. Надо просто ИМЕЮЩИЯСЯ метаданные сохранить как это положено. Почему ты этого не хочешь?

Цитировать
А вот будут ли все такие PDF и DjVu-файлы, впервые попадающие в Сеть, ОДНОВРЕМЕННО с инфоименем иметь ещё и метаданные (как ВЫ того хотите) - ещё не факт. По разным причинам (технические проблемы и человеческий фактор) такие файлы могут и не иметь метаданных.
ну вот нравятся мне рассуждения "взагали"!

Слушай, а давай проще. Обеспечь, чтобы лично твои книги, попадая в сеть, имели метаданные. Сделай для этого прогу. Ты ж понимаешь, как это важно, ну, в смысле, чтоб метаданные были? И все. Кто умный - за тобой потянется. Скажет тебе спасибо за прогу. Полезность метаданных уже сейчас многие понимают. Ну а нет - то ты поможешь понять. На своем сайте, например. Ну а кто тупой - так и пусть юзает NAMECREATOR. Все равно не долго уж осталось, время ее прошло.

Вобчем, будь проще - и народ к тебе потянется:)

monday2000

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

Надо лишь, делая любую программу, не ущемлять свободу юзера. "Не хочешь заполнять метаданные - не заполняй" - вот тот принцип, которого я буду вынужден в своей программе придерживаться. Потому что, если я попытаюсь силой заставить юзера ВСЕГДА заполнять метаданные - то тогда моей программой просто не будут пользоваться.
Цитировать
Итак, кто НЕ ХОЧЕТ - пусть пользуется NameCreator. Но твоя прога будет же лучше. Ведь правда? Вот и пусть платой за дополнительные удобства будет заполнение метаинформации.
Немного наивные ИМХО рассуждения. Плевать юзеру на мои или Ваши указивки. Юзера можно только просить - а указывать или заставлять - бесполезно.
Цитировать
т.е. если ею пользоваться - то метаданные всегда есть.
Опять же - Вы не рассматриваете вариант сторонней реализации в чужой программе моего стандарта инфоимени. В этом случае инфоимя может быть - а метаданных может не быть.
Цитировать
Вывод - ты целенаправленно не хочешь работать с метаданными.
Вывод неправильный. Просто я трезво смотрю на жизнь, и понимаю, что, как бы мы с Вами ни не хотели, чтобы метаданные всегда были в самого начала - но суровая жизнь всё равно не даст возникнуть такой идеалистической картине на 100%. Как именно не даст, почему - это заведомо оценить невозможно.

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

А вот и может (что не будет метаданных). Потому что реальный мир несовершенен.
Цитировать
Слушай, а давай проще.
"Проще" нельзя. Не стОит пытаться втиснуть сложность мира в простые схемы. Вот, к примеру, Scan Tailor - там тоже автор пытался всё сделать "проще" - получилась ерунда в итоге.
Цитировать
Обеспечь, чтобы лично твои книги, попадая в сеть, имели метаданные. Сделай для этого прогу. Ты ж понимаешь, как это важно, ну, в смысле, чтоб метаданные были?

Я-то лично, конечно, это обеспечу. Т.е. у меня будет одновременно формироваться инфоимя около 245 знаков - и одновременно автоматически метаданные такой же длины (245 знаков). Так что юзеру не потребуется лишний раз шевелить пальцем, и, даже если ему неохота будет заполнять метаданные - они всё равно автоматом хотя бы частично (245 знаков), но заполнятся.

И для ответственных пользователей будет возможность дополнительно заполнить метаданные полностью (с 245 знаков до конца).

Делать сразу заполнение метаданных целиком - а чтобы инфоимя потом из части метаданных автоматом формировалось - не хотелось бы, так это будет уже насилие над юзером (и как следствие посылание моей программы подальше).
Цитировать
Полезность метаданных уже сейчас многие понимают. Ну а нет - то ты поможешь понять. На своем сайте, например.
В этом отношении я сделаю всё, что смогу.
Цитировать
Все равно не долго уж осталось, время ее прошло.
Да, NameCreator устарел: он и метаданные не поддерживает вообще, и слишком под Колхоз заточен (например, коды областей знания в имени книги там - сугубо внутриколхозные). Представления NameCreator о параметрах качества исполнения эл. книги - тоже уже кажутся скудноватыми. Да и длина имени там не ограничивается ~ 245 символами - что оказалось неприемлемым.
« Последнее редактирование: 18 БХЭвпСам 2010, 22:07:32 от monday2000 »

kv

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