Формат NFB

ВложениеРазмер
Иконка электронной таблицы Office fb2-nfb relations.xls25.5 КБ
Иконка простого текстового файла NFB Specification_1.0.14_FR.txt32.42 КБ

начиная с 01.12.2008 ТЕМА НЕ МОДЕРИРУЕТСЯ
убедительно прошу воздержаться от нецензурных выражений, беспочвенных наездов и флейма.

изменено: 30.06.2009.
выложена четырнадцатая редакция спецификации

24.04.2009: работы временно приостановлены по субъективным причинам. возобновление планируется на середину мая этого года.
27.04.2009: жалкие попытки заняться полезным делом привели к очередной корректировке спецификации. выложена сравнительная таблица по взаимной совместимости fb2 и nfb.
05.05.2009: победил глюки оперы и залил-таки тринадцатую редакцию
30.06.2009: выложил 14 редакцию. изменений по сравнению с 13-й практически нет, уточнены отдельные мелочи, переведено в стадию "финал релиз".

формат разрабатывается как макcимально упрощенный альтернативный вариант хранения книг.

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

конвертор пока существует только из fb2 в nfb, планируется полная поддержка импорта и экспорта для формата fb2.

у кого есть конструктивные идеи/замечания/предложения - прошу высказаться.

Комментарии

Пока только об одной вещи, которую нужно, как мне кажется, добавить в формат.
Нужен тег для обозначения страниц неэлектронного оригинала. Ибо: в научной практике принято ссылаться на страницы, а потому та же самая militeria.lib.ru в своей html-вёрстке воспроизводит номера страниц оригинала, помещая их в квадратные скобки и выделяя серым цветом.

nonduc написал:
Нужен тег для обозначения страниц неэлектронного оригинала.

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

Вставить в текст можно всё что угодно. Но если необходимая вставка единообразно оформлена — это, согласись, другое дело.
Насчёт проверенности-непроверенности — да, верно, не принято. Но! — в этом плане *.djvu может старадать всё теми же недостатками неправильного распознавания, если *.djvu содержит OCR-слой. Во-вторых, *.djvu заведомо не содержит того самого дескрипшена, который делает операционально возможной автоматическую обработку единицы хранения в электронной библиотеке.
Итого: твои возражения не представляются убедительными. :)

Поддерживаю.

Цитата:
Якоря, страницы и ссылки.
---------------------------
...
Явное указание страниц исходного текста:
Эта часть предложения оказалась на одной странице [?0001] а эта на другой. Используется для перехода по номеру и отображения в псевдостраничном режиме.

^ эта вот фигня ни на какие мысли не наталкивает? :)

кстати, появилось ещё в восьмой редакции.
всем троим по 2 балла за невнимательность на уроке. :)

Уп-с-с, сорри, проворонил… :)

СерыйМыш написал:
^ эта вот фигня ни на какие мысли не наталкивает? :)
кстати, появилось ещё в восьмой редакции.

Печально...

СерыйМыш написал:
^ эта вот фигня ни на какие мысли не наталкивает? :)

кстати, появилось ещё в восьмой редакции.

Отлично!

учитывая мировые тенденции к переводу всех и вся в браузеры, добавил в планы конвертер nfb->html.
насчет целесообразности обратного конвертера пока думаю. скорее всего есть смысл оформить как функцию импорта в редакторе. кстати, вопрос: как быть со служебными реквизитами (секцией "BookInfo") при конвертации в html?
пока в ум пришло два варианта - лепить в начало файла, либо хоронить внутри в виде коментариев. жду подсказок.

Лучше, на мой взгляд, в начало файла. А если «прятать», то тогда лучше не в схрон закомментированного текста, а под внутреннюю ссылку «развернуть», которая бы оформлялась средствами css/js на манер оформления «спойлеров» и тому подобного.

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

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

Традиция, пошедшая от файлов Мошкова, двояка - или в начале текстового файла можно найти блоки информации "от сканировщика", или в самом в конце...

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

СерыйМыш написал:
конвертер nfb->html.
насчет целесообразности обратного конвертера пока думаю. скорее всего есть смысл оформить как функцию импорта в редакторе.
Мне зело нравится paste в FBE2: можно копипастить хоть из word'а, хоть из wortviewer'а, хоть из firefox'а - берутся стили, ссылки... Приятно и удобно. Можно такое в редакторе?
И, думается, не помешало бы позволить хранить бинарные файлы (рисунки и т.п.) двояко: в готовом .NFB пусть будут заMIMEченными внутри, а на этапе редактирования хотелось бы иметь ссылки на внешние файлы - чтобы можно было быстро изменить картинку (размер, контраст, ...), не делая дополнительных телодвижений по расшивке .NFB-книги и сшивке её обратно. Если ещё и вьюер такое поддержит - будет вообще клёво. OK?

Для текстовой секции помимо алфавитного указателя следует также предположить предметный указатель (SubjectIndex).

ЗЫ. Есть и другие типы указателей — персон, географических названий, принятых сокращений… Неплохо бы над ними подумать, а? Вот есть, к примеру, библографический указатель, который в отличе от простой «библиографии» служит адресатом для отдельного класса сносок в тексте, — сноски при этом оформлены по принципу [номер в списке, страница].

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

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

Так переназови его в просто «Указатель (BookIndex)» и дай соотв. пояснение, что сюда относится любой указатель.
(Хотя, мне кажется, лучше их специфицировать, не так уж их и много, этих типов.)

Кажется, не хватает в BookInfo блоков для следующих типов текстов:
1. Сборник, у которого составитель не сам автор. — Нужен блок «Составитель».
2. Отдельное произведение, которое в данном издании снабжено предисловием (послесловием), вступительной (заключительной) статьёй (т. е. такая статья может и не быть собственно предисловием послесловием к произведению, но быть обзором творчества автора etc.), комментариями. — Нужен блок «Автор предисловия (послесловия), сопроводительной статьи или комментариев».
3. Коллективная монография (или какие-нить материалы конференции), которая издана под отвественной редакцией кого-то. — Нужен блок «Ответственный редактор».

nonduc написал:
Кажется, не хватает в BookInfo блоков для следующих типов текстов:
1. Сборник, у которого составитель не сам автор. — Нужен блок «Составитель».

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

nonduc написал:
2. Отдельное произведение, которое в данном издании снабжено предисловием (послесловием), вступительной (заключительной) статьёй (т. е. такая статья может и не быть собственно предисловием послесловием к произведению, но быть обзором творчества автора etc.), комментариями. — Нужен блок «Автор предисловия (послесловия), сопроводительной статьи или комментариев».

аналогично. полагаю, что разводить отдельные реквизиты имеет смысл только для автоматизированного поиска/сортировки. поиск предисловия по его автору менее вероятен, чем поиск самой книги с целью посмотреть её предисловие.

nonduc написал:
3. Коллективная монография (или какие-нить материалы конференции), которая издана под отвественной редакцией кого-то. — Нужен блок «Ответственный редактор».

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

последнее время перечитывание предложений и получившейся спецификации наводит меня на мысль о попытках "объять необъятное и впихнуть невпихуемое" (с).
мб нет смысла на каждый вероятный случай делать отдельный способ воплощения? многие вещи с некоторыми условностями могут быть приведены к общему случаю, что упростит и реализацию, и использование.
практика показывает, что 80% узкоспециальных функций в универсальных системах оказываются нафиг никому не нужны. а те 2% пользователей, которым эти функции могут быть нужны, вполне способны обойтись и без них.
предлагаю расширять спецификацию только когда станет очевидно, что другим путём идти нет смысла. готов конструктивно обсудить преимущества и недостатки разных подходов, но только при наличии хороших аргументов. в остальном - чем проще/меньше/универсальнее, тем лучше.

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

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

Далее, насчёт «необъятного и невпихуемого» — что именно «необъятного и невпихуемого» в составителе, авторе предисловия или статьи или ответственном редакторе?

Наконец, неужели тебя никак не смущает откровенная несуразица в каталоге Либрусека с произведениями, у которых «Автор неизвестен» или «Коллектив авторов», а? Это же всё фигня на постном масле именно потому, что в *.fb2 нету блока для составителя и отв. редактора.

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

в любом случае, основная идея формата допускает наличие любого дополнительного реквизита, даже если он не объявлен в спецификации. к примеру, EDIC: (editor-in-chief) для ответственного редактора, или COMP: (composer) для составителя. вопрос в том, как потом этой информацией воспользоваться.

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

Ну не путай ты себя «поиском», не путай! Я поиск никак не рассматриваю, я рассматриваю только каталогизацию издания по его данным. И в данные издания может входит помимо автора основного текста также автор сопр. статьи, составитель и т. д. Эти данные для этого издания никак не являются «дополнительными» — они основные. Вот пример: Гамсун К. О духовной жизни современной Америки. Сборник: статьи, письма // Сост. и предисловие Э. Панкратовой. Перевод: Э. Панкратова, А. Сельницин, Н. Шинкаренко, О. Комарова, Н. Будур. СПб.: Владимир Даль, 2007.

AUTH:Гамсун К.
COLL:О духовной жизни современной Америки.
FORM:статьи, письма
TRAN:Э. Панкратова, А. Сельницин, Н. Шинкаренко, О. Комарова, Н. Будур
PUBL:СПб.: Владимир Даль, 2007.
INFO:Сост. и предисловие Э. Панкратовой.

внимание, вопрос: в чём трудность заполнить инфу о книге таким вот способом?

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

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

Тэк-с, хорошо, отнёс ты «Сост. и предисловие Э. Панкратовой» в рубрику-свалку «INFO», ладно, только дальше не очень понятно, что как ты поместил в авторы всего сборника только Гамсуна, когда автором первого произведения в сборнике — именно «Предисловия» — является вовсе не Гамсун, а Панкратова…

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

Далее, этот сборник у тебя не попадёт в рубрику работ Элеоноры Панкратовой, хотя это её сборник, — если ты только специально не обучишь свой каталогизатор выковыривать из «INFO:» составителя и заносить данные об этом сборнике на его страницу (карточку).

«* Стиль: Повесть, рассказ, поэма и т.п.» — неправильно! Это не стиль, а форма. Форма художественного произведения.

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

Блок «YEAR: год написания.(0/1)» явным образом относитс к данным об оригинале, но не к данным о конкретной публикации: произведение, написанное (или впервые опубликованное) в 1800-каком-то году, теперь публикуется в этом 2000-каком-то году, — здесь первая дата есть год написания, а вторая дата год издания. — Нужен блок «YEPU: год публикации.(0/1)».

И «год написания лучше переименовать в «YEOR: год написания или оригинальной публикации.(0/1)» — чтобы не было искушения в этот блок вписать данные о годе конкретной публикации.

смотрим внимательнее:

YEAR: год написания.(0/1)
PUBL: наименование издателя, город, год публикации. (0+)

Да, я ещё раз проявил невнимательность, прошу прощений.

Также: нужны дополнительные блоки в случае переводного произведения — для оригинального имени автора, оригинального названия произведения, оригинального названия цикла (серии) и наименования издателя.

ЗЫ. Наши умельцы вроде работников АСТа так ухитряются переводить названия, что фик вычислишь что именно переводилось. Да и имена авторов нередко видоизменяют по сравнению с общепринятым порядком транслитерации. Например, Carl Hiaasen должен транслитерироваться как Карл Хайесен ( так было сделано в «Крахе „Волшебного королевства“» 1993 г.), однако в последующих изданиях фамилию поправили на Хайасен. Larry McMurtry сейчас фигурирует как Макмуртри, хотя правильно — Макмёртри, и не исключено, что другие издатели исправят ошибку.

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

Цитата:
*Если у книги (рассказа/повести/итп) несколько авторов, то каждый указывается в отдельном блоке AUTH. Авторы должны быть указаны либо на языке текста, либо на языке оригинала. Допускается указание имени автора на нескольких языках, каждая запись в отдельном блоке. Для организации поиска по псевдонимам и разноязычным вариантам записи автора должны использоваться средства программ-каталогизаторов. Желательно указывать имя автора в точности как в печатном образце.

или мы о разном говорим?

Дык, для переводного произведения имя автора на языке оригинала нужно обязательно указывать, а не только «допускать возможность». «Обязательно» — это всегда, когда известно. И делать это нужно в особом блоке, который не путался бы с соавторским блоком, — то есть программа-каталогизатор должна воспринимать имя автора на языке оригинала как другой тип данных, чтобы не делать из Larry Jeff McMurtry соавтора Лэрри Макмуртри.

Кстати, для «Сборника» у тебя предполагается только один блок: «COLL: Название сборника. (1)». И не предполагается давать оригинальное название сборника, если этот сборник переведён.

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

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

про сборник согласен. поправил в проекте 13 редакции.

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

Да, и кроме того, почему у тебя «Автор - Фамилия, Имя (, Отчество)», а «переводчик» — не дифференцированно? Если переводчик, например, будет прописан «Набоков Владимир» или «Владимир Набоков», то программа распознает, что это один и тот же переводчик или сочтёт их разными? :)

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

Э-э-э, не взрывайся, пжста! От твоего интеллектуального здоровья зависит чёткость разрабатываемого стандарта. :)

Да, так вот, есть разные виды авторства. И они в разной мере присутствуют в разных типах публикации. Для одних публикаций кроме автора художественного текста никакого больше авторства и нет — есть текст без картинок и всё… Для иллюстрированного издания художественного произведения будет актуальным помимо первого и второй тип авторства — где автором будет художник-иллюстратор. А в переводном художественном произведении с картинками будут уже актуальными три типа авторства — 1) автор художественного текста, 2) автор перевода художественного текста и 3) автор картинок к художественному тексту. Если в издании появляется ещё и статья (про автора худ. текста, про автора-переводчика или про автора-художника, не важно), по актуализируется ещё и четвёртый тип авторства… И т. д., и т. п. Возьми разные издания Гомера и ты сразу поймёшь разницу между каким-нить массовым изданием без картинок, массовым изданием с картинками и изданием без картинок, но с научным комментарием. Ну и переводчики у Гомера были разные, это само собой… А бывает ещё и так, что один и тот же перевод какого-нить классического текста в разных изданиях появляется под разными редакциями, например, Платон в переводах Егунова обычно дополнительно редактируется.

Теперь один пример из текущей практики на Либрусеке. Сейчас произведение идентифицируется по связке «Автор—Название», а потому часто приходится названия расширять «вручную» (помимо дескрипшена *.fb2) — добавлять переводчика в скобках, чтобы отличить разные переводы одного и того же произведения. Хотя можно было бы автоматом идентифицировать произведение по связке «Автор—Название—Переводчик» и надобность в таком «ручном» расширении названия отпала бы. Но! При этом есть книги, которые отличаются своими иллюстрациями, а для таких названий никакой новой связки не сделаешь, потому что дескрипшен *.fb2 не предусматривает информации об авторе-художнике. Ты же эту информацию должен предусмотреть.

(Замечание в скобках. Знаешь ещё и по какой причине Грибов подтормаживает с *.fb3, как мне кажется? Потому что ему надо представлять в рациональном виде «Тип связи субьекта (автора, организации) с произведением на основе RUSMARC’а» (основа, должен я отметить, не ахти какая основательная), но это морока не меньше, чем морока с более-менее разумным списком жанров. А с жанрами у Грбова уже вышло хреново. Потому что залепил он их то ли с кондачка, то ли с бодуна, — но никак не по тщательному и трезвому размышлению и классификационному анализу.)

Теперь закончу. Зря ты думашь, что фигура переводчика не такая уж значительная. Когда я сталкиваюсь с хорошим переводом (он ныне большая редкость, между прочим), первое, что я делаю — ищу то, что этот переводчик ещё переводил. Так у меня последний раз было с Александром Рахубой, например. Переводчик ведь в известном смысле соавтор, если вообще не… соперник. :) Ну, то есть, знающий человек будет искать Шекспира именно в переводах Лозинского, а переводы Пастернака будет обходить далё-о-окой стороной.

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

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

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

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

в результате имеем возможность при обработке данного реквизита однозначно выделить фамилию, а при наличии имени-отчества или инициалов провести дополняющее сравнение при отборе/поиске.
в итоге суть идеи сводится к тому, что реквизит, описывающий любого человека, должен быть в определенном виде:
Фамилия, [Имя [, Отчество]|Инициал имени [,Инициал отчества]]
(не уверен, что скобки правильно, никогда не любил регулярные выражения).
деление запятыми позволяет вычислить количество указанных субреквизитов, и разделить их для дальнейшей обработки.

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

получаем:
AUTH:Стругацкий, Аркадий, Натанович|Стругацкий, Борис, Натанович

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

вот.
теперь о катологизации как таковой. при сортировке и выводе списком необходимо определить, по каким критериям строится список. например, есть серьёзная проблема с несколькими авторами при построении списка по авторам. если указывать в списке книгу несколько раз, по одному для каждого из соавторов, то получается, например, что два раза подряд идет одна и та же книга "Трудно быть богом", сначала для автора "Стругацкий Аркадий", потом для "Стругацкий Борис".
с поиском всё проще. задаём условие, например реквизиты человека, и получаем список книг, в которых указанный товарищ может быть автором, соавтором, редактором и вообще кем угодно.

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

займусь переделкой спецификации.

СерыйМыш написал:
по набору символов можно определить языковую принадлежность

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

Наверное, это была описка-оговорка — язык определяется по «LANG: идентификатор языка текста согласно ISO 639. (0/1)» и «SRCL: идентификатор языка оригинала, если отличается от LANG. (0+)».

действительно невнятно выразился. стереотип о том, что книга исходно "не на русском", а перевод "на русский" слегка скособочил моё восприятие действительности.
в реквизите LANG должен быть указан язык текста.
в реквизите SRCL - язык оригинала.
соответственно имеет смысл организовать заполнение полей так, чтобы в первом вхождении поля,например AUTH, было указано имя автора на языке текста, а во втором - на языке оригинала.
в теории можно требовать однозначного заполнения всех пар двуязычных реквизитов, если указан язык оригинала, и он отличается от языка текста. но это всё только усложнит систему контроля валидности.
про набор символов - имелось ввиду, что в unicod-е значительно различающиеся языки имеют разные диапазоны. подумал про перевод с английского на немецкий или французский, и понял, что тут всё не так однозначно.
вводить дополнительные реквизиты или блочные обвязки для групп реквизитов на разных языках как-то не хочется... я всё-таки пытаюсь упростить, а не запутать всё окончательно. в fb2 кстати тоже невозможно определить, на каком языке дано название или имя автора. и пока это никому особо не мешало.

СерыйМыш написал:
в fb2 кстати тоже невозможно определить, на каком языке дано название или имя автора. и пока это никому особо не мешало.

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

в том то и дело, что всего одно.
в результате этого, например, у меня в каталоге получилось два разных автора - Терри Пратчетт и Terry Pratchett, у каждого свои книги, причем все книги на русском. в результате - некоторая несуразица и неудобство. имея два написания в одном файле можно убить сразу трёх зайцев:
1. автоматизированно собрать имена одного и того же человека, написанные на разных языках.
2. собрать воедино все книги автора, независимо от того, на каком языке в файлах заданы имена, и на каком языке сами книги.
3. дать шанс человеку найти книги нужного автора даже в том случае, если транслитерация его имени выполнена неверно.
вот как-то так.

Мне кажется, что нужна дифференциация блока «AUTH» точно так же, как дифференцирован блок «LANG», — то есть отдельный блок для «имени автора» и отдельный блок для «имени автора в оригинале». Чтобы пользователю было очевидно, в каких случаях нужно помимо одного имени автора указывать и другое.

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

СерыйМыш написал:
в fb2 кстати тоже невозможно определить, на каком языке дано название или имя автора

Почему же?
fictionbook/description/title-info/lang ru
fictionbook/description/title-info/author Нил Стивенсон
fictionbook/description/title-info/book-title Лавина
fictionbook/description/src-title-info/lang en
fictionbook/description/src-title-info/author Neal Stephenson
fictionbook/description/src-title-info/book-title Snow Crash

потому же:

fictionbook/description/title-info/lang ru
fictionbook/description/title-info/author/first-name Terry
fictionbook/description/title-info/author/middle-name David John
fictionbook/description/title-info/author/last-name Pratchett
fictionbook/description/title-info/book-title Цвет волшебства (пер. И.Кравцова под ред. А.Жикаренцева)
fictionbook/description/title-info/sequence number="1" name="Discworld (Плоский мир)"
fictionbook/description/document-info/id 5AA41F44-91A2-4001-91D4-F7A5293888D1

методика заполнения - "как бог на душу положит"

а поскольку уважаемый
document-info/author/first-name Александр
document-info/author/middle-name Михайлович
document-info/author/last-name Клюквин
document-info/author/nickname Shaman
не имел возможности указать автора на двух языках, но имел непреодолимое желание указать автора на языке оригинала, получилась каша-малаша.

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

и кстате - тег "src-title-info" валидатор отрыгнёт, скривившись, ибо нет в схеме разрешения на такую самодеятельность. "src-lang" есть, "src-url" есть, даже "src-ocr" есть. "src-title-info" нету.

СерыйМыш написал:
методика заполнения - "как бог на душу положит" [...] получилась каша-малаша.
Если нет шаблона с полями ввода - может и такое получиться, если есть шаблон... тоже может. И имена тэгов не всем указ. :-(
СерыйМыш написал:
тег "src-title-info" валидатор отрыгнёт, скривившись, [...] "src-title-info" нету.
В какой версии спецификации? В 2.1 точно есть, а большинство валидаторв позволяют обновлять схемы.

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

спецификацию fb2 версии 2.1 специально вдумчиво прочитал. каюсь, предыдущее моё заявление про отрыжку основывалось на версии 2.0, и практических испытаниях соответствующего софта.
Вот только найти софт с вразумительной поддержкой fb2 v2.1 мне почему-то не удалось. наверное плохо искал.
надо будет учесть возможность выбора версии 2.0 или 2.1 при переделке конвертера.

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

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

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

PART: 0001
TITL: Название книги. (1/2)
AUTH: Автор(ы) - Фамилия, Имя (, Отчество). (1/2)
EDIC: Ответственный редактор (0/2)
ADDA: Автор дополнительных материалов. (0/2)
TRAN: переводчик.(0/2)
ILLU: Художник-иллюстратор (0/2)
YEAR: год написания.(0/1)
SEQU: название авторской серии, цикла и т.п. (0+)
FORM: Форма произведения (0/1)
KEYW: ключевые слова для поиска (0+)
PART: 0002
...
ENDP:

далее каждая часть обозначена своей меткой:
NFB_Text:0001
...
NFB_Text:0002
...
NFB_End

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

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

Страницы

X