Характеристики периодических изданий

"Характеристики" - переменные параметры, описывающие издание в целом.

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

Список характеристик обсуждаем, расширяем и уменьшаем

Обязательные параметры:
1. Основное заглавие (с титульного листа, по ГОСТу 7.1) на языке издания. Если используется графика, отличная от латиницы или кирилицы, то в русской транслитерации
2. Унифицированное имя (уникальное) для пакетной обработки. Наверное, транслит?

Все остальные параметры опциональны (от нуля и более повторений).

3. Основное заглавие на рус. языке (перевод!), если язык издания не русский
4. Язык издания (трехсимвольный код по ISO..., в кр. случае? 2-х символьный как в FB2),
5. Альтернативное заглавие на языке издания - другие используемые варианты - с аббревиатурами и пр.
6. Альтернативное заглавие на рус. языке (-"-)
7. Место издания
8. Издательство/Издатель
9. ISSN
10. Редактор
11. Периодичность - текстом и числом (макс. кол-во номеров в год)
12. Оф. сайт издания
13. Неоф. сайт издания
14. Логотип издания (ссылка)
15. Формат (в смысле размер?)
16. Классификаторы (УДК, ББК)

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

это же будет выпадающий список список, вот кстати неплохой пример. http://free-books.dontexist.com/lang.txt наиболее распространенные наверху не понимаю, что это даст, будет же таблица, и там будет указано когда и что издавалось, к тому же периодичность издания может меняться у журнала если скрипт может понимать кириллицу в файлах на фтп, тогда наверное не надо.

ну и надо еще поле, где указывается соотв. папка на фтп где лежит подшивка - обязательно

в остальном +1

Нет и не надо. Уберем. Да. список. Конечно. А таблицу кто и как делать будет? мы же при создании записи на издание из тех же летописей (или др. источников) и возьмем. Может текстом и излишне ("Ежемесячный","еженедельник"...), а вот к-во номеров по годам мы и укажем. Причем, напр. 1-й год вышло 3 номера (окт-дек. для ежемесячников), то указываем "3"-"1971-10-01"-"1971-12-31", потом 10 лет : "12"-"1972-01-01"-"1981-12-31" а потом 1 раз в два месяца: "6"-"1982-01-01"-"1999-12-31"... Здесь сдвоенные и т.п. номера не учитываются, даже если они и были. Но вот когда мы начнем раскладку номеров по годам, то там, напр. будет : "1980"-"1"("физ." номер)-"1"-"99", "1980"-"2"-"2/3"-"100/101", "1981"-"3"(или 4, не важно)-"4"-"102"... Тут не тривиально. Как я представляю технологию "пакетной загрузки", будет поле "Загрузить пакетный файл". Мы указываем текстовый файл на нашей машине, в котором в строчке будет 3 поля: "Имя для СУБД" (это и есть что-то вроде "Унифицированное имя"_ГОД_НОМЕР), реальное имя файла, путь где файл лежит сейчас (URL ftp://). Но этот текстовый файл может быть в 16-битной кодировке (Юникод), комбинированной - UTF-8 или 8-битной CP-1251. Кто будет разбирать - в какой кодировке имена? Или тогда нужно жестко требовать одну-единственную кодировку? Это на 3-м уровне иерархии. Мы же про 1-й уровень говорим.

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

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

но по моему с кириллицей мы можем совладать, на ftp://free-books.dontexist.com она корректно отображается и файлы так поименованные скачиваются

вот пример работы ftp с кириллицей
http://free-books.dontexist.com/comics/?s=%EF%E0%F3%EA&page=10

Алгоритм создания издания скипнут. Я примерно так и представляю тоже. Может мы в каких то деталях расходимся, но не принципиальных. Завтра я сделаю ввод изданий на тесте (сегодня начал, но не успел), тогда посмотрим, как получится.

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

"Физические" номера не обязательно должны быть последовательными, главное, чтобы они соответствовали порядку выхода реальных номеров. Напр. у ежемесячника при создании сформируется на каждый год по 12 физ. номеров. Но если потом окажется, что в каком-то году вышло два сдвоенных номера (напр. 4/5 и 10/11) то иы просто удалим любые 2 физ.номера. главное, чтобы физ.номер журнала № 6 был больше №4/5 а тот больше №3. Напр. это может быть: 1,2,3,4,6,7.8,9,10,12 или 1,2,3,4,5,6,7,8,9,10. Как я уже писал, физ номера будут видны только пока не пропишем реальные номера, После этого они будут внутренними переменными, используемыми для сортировки. (известно, что стандартные алгоритмы сортировки расположат номера: 1,10,11,12,2,3...)

По кирилице- ФТП то кирилицу понимают без проблем, но если сервер и клиент используют одну кодировку - иначе появляются крякозябры - типа: йцукен или йцукен вместо "йцукен". Тоже и с файлами.

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

тогда может быть путаница, я могу указать ведь последний номер в году как 12-01, а могу как 12-31, а если в году выходило 24\36\52 номера, то вообще ужас, что там можно с датами наворотить не уверен, что это подходящий формат столбца базы для нашего случая,тут годится обычный числовой формат столбца, то есть привязка должна вестись не датам, а скорее к порядковому номеру издания за год 2007 1 2 3 4 5-6 7 8 9 10 11-12 2008 1___2___3-4____5____6

2009 _____________1__2__3 2010 1 2 3 4 5 6 7 8 9 10 11 12

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

По датам - а) для раскладки номеров будет использоваться только год это уже делается, б) если нужна будет полная дата, то вводиться она будет в "человеческом" виде либо через листбоксы либо через java-календарь. Примеры я привел во внутреннем представлении СУБД. Так вводить, естественно не придется.

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

... 17. Логотип издания (ссылка на картинку)

Связи между изданиями: 18. Прежнее название (ID) [комментарий - при смене названия требуется смена ISSN, т.е. это как бы другое издание] 19. Переименован в... (ID) 20. Объединилось с... (ID) 21. Выделилось из... (ID)

KaraBY

а всякие позаголовки куда писать? то есть для журнала например Химия и жизнь надо делать 2 подшивки, тк 2000-х годов оно переименовалось в Химия и жизнь - XXI век

Да. 22. Подзаголовок Думал, но забыл. 3 Названия - сейчас снова ХиЖ. Наверное, в подобных случаях одна подшивка. Варианты названия и варианты ISSN (кстати я не нашел ISSN у ХиЖ-21) отражаем в характеристиках. Хотя всё можно изменить на лету - будет команда типа "объединить издания" (и, вероятно, обратная - "разделить издания")

KaraBY

забыли еще поле: продолжает ли оно сейчас выходить, или закрылось.

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

Признак: "Издание прекращено или продолжается" определяется при создании/редактировании издания - в форме (см. "Добавить издание" на тесте) есть поле "Год издания последнего номера (пусто, если издание продолжается)" Исходная ("грубая") раскладка номеров "на будущее" будет формироваться 1-го января нового года исходя из периодичности предыдущего года. На весь год. Потом, по мере выхода номеров, мы будем её корректировать и прописывать данные новых номеров.

вообщем, я жаждю уже попробовать что-нибудь залить

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