Open Journal Systems (OJS) – это система управления и публикацией журналов, которая была разработана «Public Knowledge Project» и финансирована из федерального бюджета (США) по улучшению доступа к научным исследованиям.

Особенности OJS:
OJS устанавливается локально и локально управляется.
Редакторы настраивают требования, секции, процесс рассмотрения и т.д.
Отображение и управление содержимым через интернет.
Модуль подписки на доступ к содержимому.
Полная индексация содержимого системы.
Инструменты для чтения содержимого выбираются редактором.
Уведомления по почте и система комментариев для читателей.
Полная контекстно-зависимая система интерактивной справки.

OJS - это программное обеспечение с открытым исходным кодом, доступное для всех журналов по всему миру, созданное для открытого доступа к публикациям, открытый доступ может повысить круг читателей журнала, а так же его вклад в общественное благо в глобальном масштабе.
Домашняя страница системы http://pkp.sfu.ca/?q=ojs
Пример реализации (на укр. языке) Демо
Поставил у себя, но не хватило терпения все заполнить. Ставится достаточно легко.



Редактировано 1 раз. Последний раз 18.02.2012 03:42 пользователем woodyfon.

Очевидно, речь о публикациях, которых нет в "открытом" интернете"?

Электронным научным журналам давно уделяется большое внимание. Видимо, основная причина в их оперативности по сравнению с бумажными. Одно время даже считалось, что в библиотеках нужны именно такие, или даже только такие, CD-ROM! Ну это смотря в каких библиотеках. Идею активно пропагадировала Т. В. Майстрович из РГБ, потом занялась "просто" ЭБ [www.rusneb.ru]
ЗЫ. Опять не понял, в чем разница между ЭА и ЭБ.

irbis_arbat@mail.ru



Редактировано 1 раз. Последний раз 02.04.2012 09:05 пользователем Lavrinovich.

Что интересно, это я вообще впервые вижу, администратор не имеет всех прав. Чтобы добавить выпуск номера журнала и иметь возможность добавлять/расписывать статьи необходимо предварительно создать Editor (Редактора). Почему первый пользователь (обычно же root admin) не "бог" непонятно. Возможно, политика и логика разработчиков. Ведь редактор же должен знать лучше как нужно управлять журналом. Хотя на практике это далеко не так. Но что дейстивтеьно удивляет - так это то, что добавить журнал может только администратор системы. Хотя здесь прослеживается логическая структура. Администратор дает возможность добавлять выпуски, авторам, в свою очередь, отсылать статьи в журнал. Но только менеджер (технический редактор?) может настроить внешний вид журнала в системе.

Видимо, "логическая структура" такая, что администратор - это айтишник-железячник, а редактор - библиотекарь-библиограф или "эксперт", т.е. специалист в данной предметной области (физик, химик)... В любом случае они должны постоянно взаимодействовать и это действительно не очень удобно. Специфика организации работы в НИИ? См. [irbis.gpntb.ru]

irbis_arbat@mail.ru



Редактировано 1 раз. Последний раз 26.04.2012 07:58 пользователем Lavrinovich.

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

Щас вот менял админский пароль, угадайте как? Правильно, через ковыряние в SQL базе. Причем в мануале (вернее в FAQ из которого вместо ответа идет ссылка на форум) в одном из примеров указан MD5 хэш а в другом SHA1, как раз в админском случае указан SHA1, а надо MD5 :) И с точки зрения установки и с точки зрения администрирования от системы волосы в жилах на спине стынут дыбом, по сравнению с тем же dspace.



Редактировано 2 раз. Последний раз 24.08.2013 19:31 пользователем IdeaFix.

Коллеги, а всётаки, кто как сабж бэкапит? Я делаю дамп базы, копию wwwroot и files, но быть может это не оптимально?

IdeaFix написал(а):
-------------------------------------------------------
> Коллеги, а всётаки, кто как сабж бэкапит? Я делаю
> дамп базы, копию wwwroot и files, но быть может
> это не оптимально?

Используем виртуальные мышины vmware. Бекапим всю виртуальную машину целиком средствами veeam backup.

Для сайтов бекапить mysqldump-ом и переносом файлов - вполне нормальный вариант. Только бекап на той же машине - это не бекап.

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

ojs хранит файлы локально. Эьл касается и контента и некоторой части шаблонов. В базе по большому счету слезы. А учитывая какое количество кастомизаций приходится делать в интерфейсе, причем регулярно, вылавливая баги, действительно на ум приходит только дифф бэкап виртуалки, чтобы ничего не забыыть :( Но имхо это не правильно.

Админ не бог - это чтобы рядовые редакторы не имели соблазна редактировать журналы с божественными полномочиями. Шансы что эксперты Лавриновича внезапно и профессионально поломают систему резку убывают.

Вывод какой? Можно рекомендовать? Или интерфейс устарел и читатели относятся к системе равнодушно?

Чем это отличается от простого заточенного сайта с журналами кроме организации рабочего процесса?

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

Хотя, в отличии от "сайтиков журналов" тут и оркиды и авторские портфолио и OAI-PMH и пр. отраслевые вещи, прикручивать которые к друпалу мягко говоря не тривиально.

Воспринимать OJS как сайт издательства или сайт журнала/ов не правильно. У него другая задача.

Drupal:
OAI_PMH [www.drupal.org]
метаданные берет из [www.drupal.org]

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

Профиль автора можно элементарно добавить самостоятельно. Правда немного попрогать придется. Благо спецов по друпалу как грязи.

Впрочем, я не утверждаю что друпал лучше OJS. Но хочется понять для решения каких задач можно рекомендовать использование OJS. Про то и вопрос :)

Для решения задачи создания с нуля полностью электронного издательства OJS очень подходит. Особенно когда коллектив редакции авторов молод и быстр умом.

Мы пытаемся перезапустить у себя "традиционные" редакции на OJS, многие из них очень малочисленны (1-3 человека), журнал выходит 4 раза в год, имеет индекс подписки, иссн и не нулевой ндекс РИНЦ, но... у меня с большим трудом получается лишь дублировать все действия редакций в OJS, а они работают по старинке, им так проще. Убедить их что это не "сайт журнала. который нужен для аккредитации", а "реальный инструмент для создания электронной редакции" у меня не выходит.

Но это одна сторона... другая же сторона - команды молодых аспирантов/докторантов и постдоков, которые запускают полностью электронные журналы по естественным наукам на английсокм, по каким-то грантовых программам в европе хапают иссн, регистриуются в DOAj и в течении 2-3 лет попадают в скопус/вос и начинают ЗАРАБАТЫВАТЬ продавая страницы в своих журналах. Сам видел три таких журнала. вполне себе вышли в кэш, стартовали еще на 1-ой версии OJS.

Т.е. отличия от dspace - возможность продавать и оптимизация под журналы?
Просто я не увидел полнотекстового поиска в фичах системы.

DSPACE и OJS - это разные несравнимые системы.

DSPACE - архив вечного хранения с механизмами харвеста и различными PURL. В DSPACE даже сущности автора нет (пока).

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

Эти два инструмента нормально так работают в паре. например, из OJS по OAI автоматом выгружать препринт в DSPACE.

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

P.S. Федору не смотрел.

ПО OJS понятно.
Это уже офтопик пошел, его бы в отдельную тему:
Чем invenio, dspace, eprints разные? Все три - открытые репозитарии.

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

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

У всех продвинутый поиск.

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

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

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

Пример в Украине

[journals.uran.ua]В&sort=title

На этом сайте жестко и наверное правильно, что жестко :) собирают журналы. Поэтому для пользователей ИРБИС, возникает ОГРОМНОЕ желание иметь ТИПОВОЙ импорт аналитики с этой платформы, конкретного номера журнала, чтобы не заниматься аналитической росписью. В OJS есть возможность настройки экспорта записей в XML-формате с метками MARC21. Среди пользователей ИРБИС в Украине, есть такие университеты, которые работают с OJS платформой и курируют в университетах этот процесс (помогают редакциям внедрять OJS). Эти пользователи готовы опробовать предложения сообщества! Желательно, на мой взгляд встроить в ИРБИС типовое решение по импорту и настроить в свою очередь, в OJS некую строчку в меню типа "Экспорт в MARC21". Мне показывали интерфейс OJS и там есть строка "Экспорт в Cross Ref", вот я и подумал.. :) Есть информация, что кто-то из пользователей сделал возможным импорт записей в OJS из ИРБИС, т.е. как я понял аналитику за прошлые годы, в виде стороннего приложения. Одним словом, мы ждем и надеемся!

levr
Не надо поощрять забивание гвоздей микроскопом. Если хочется забивать гвозди микроскопом - готовое коробочное решение есть у НЭИКОН, называется elpub.

Но знаете что самое забавное в этой ситуации? Вы наверное сходу даже не представляете почему Ваше предложение аналогично забиванию гвоздей оптическими приборами :) Простите, наболело.... сопровождаю OJS.

Не надо поощрять забивание гвоздей микроскопом. Если хочется забивать гвозди микроскопом - готовое коробочное решение есть у НЭИКОН, называется elpub.

сколько оно стоит? как попробовать? есть ли бесплатная демо-версия? кто из пользователей ИРБИС опробовал решение? .. одним словом дайте ссылочку на инфу о продукте... среди пользователей ИРБИС в Украине, есть такие, которые активно работают с НЭИКОН... могут ли они получить доступ к этому продукту?


Но знаете что самое забавное в этой ситуации? Вы наверное сходу даже не представляете почему Ваше предложение аналогично забиванию гвоздей оптическими приборами :) Простите, наболело.... сопровождаю OJS.

отлично, что сопровождаете OJS... по моей с вами переписке, знаю, что вокруг вас и ИРБИС-ы есть.... почему, по вашему мнению, ИРБИС-пользователи, не захотят использовать или уже не пользуются, возможностью импорта записей из OJS?

[elpub.ru] - тут весь их список, белорусы точно есть, украинцы должны быть имхо.

Это глубоко кастомизированный OJS, с закрытыми (ага, в нарушение GPL) исходниками. Многие родовые травмы OJS решены, многие самобытные травмы добавлены.

Меня коробит от идеи использовать OJS как инструмент для упрощения прохождения регламентных процедур.

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

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

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

P.P.S.
Опыта работы с АБИС в целом и АБИС ИРБИС у меня практически нет.

elpub лицензию GPL не нарушает. Обычная GPL вообще не работает пока человек не начинает распространять работу.

Единственная из GPL like лицензий, заставляющая раскрывать измененный код, который используется на собственных серверах сети и не распространяется в виде ПО - Affero GPL, но OJS выпущен не под ней. Так что не надо хулить на создателей :D, еще в суд подадут за клевету .

Если OJS поддерживает OAI-PMH, то в нем точно есть Dublin Core и, может быть MARC21. Самое разумное в таком случае, чтобы производители ИРБИС написали харвестер, который бы можно было натравливать на OAI-PMH и он бы сам синхронизовал записи. Я это пожелание Кириллу высказывал, но, видимо, нет особого спроса :)...

Обратную задачу (синхронизация метаданных из ИРБИСа в уже свою библиотеку) я в целом решил с помощью другого Кирилла, там схема такая: yazproxy цепляется к Z64 чтобы предоставить записи ИРБИСа как SRU-сервер. Дальше остается кидать в SRU-сервер поисковые запросы, получать ответы и синхронизовать метаданные.

Лучше бы, конечно, ИРБИС обзавелся сам OAI-PMH провайдером, но видимо это все настолько редко востребованно, что разработчикам такую штуку созидать не интересно. Отрасль не доросла ))

IdeaFix: ну так best practice то какой?

Редакция подготовила журнал в OJS. А дальше?

И levr упомянул способ импорта аналитики. Вот тут я не слушал чтобы кто-то у нас в стране аналитику (скачивание, просмотры и всякие там подобные метрики) как-то стандартизованно хранил и тем более экспортировал/импортировал.

[elpub.ru] - тут весь их список, белорусы точно есть, украинцы должны быть имхо.

понял.. посмотрю...

Это глубоко кастомизированный OJS, с закрытыми (ага, в нарушение GPL) исходниками. Многие родовые травмы OJS решены, многие самобытные травмы добавлены.

Меня коробит от идеи использовать OJS как инструмент для упрощения прохождения регламентных процедур.

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

Но подавляющее большинство редакторов воспринимает OJS как сайт журнала, наполнять который должен "какой-то программист", а у редактора и другой работы навалом.


согласен ... МНОГИЕ редактора именно так и воспринимают..... а то что они делают два раза одно и тоже разным инструментом :( плохо, но моя задача ОБЛЕГЧИТЬ жизнь моим пользователям.... и может в таком случае пользователи ИРБИС уговорят редакторов работать исключительно на OJS, т.е. на одном инструменте, т.к. именно такая работа им облегчает жизнь....

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

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

значит все еще впереди :)

P.P.S.
Опыта работы с АБИС в целом и АБИС ИРБИС у меня практически нет.

ок!

Если OJS поддерживает OAI-PMH, то в нем точно есть Dublin Core и, может быть MARC21. Самое разумное в таком случае, чтобы производители ИРБИС написали харвестер, который бы можно было натравливать на OAI-PMH и он бы сам синхронизовал записи. Я это пожелание Кириллу высказывал, но, видимо, нет особого спроса :)...

есть спрос.. к сожалению разработчики его игнорируют... а как заставить их его НЕ игнорировать... не понятно...

Обратную задачу (синхронизация метаданных из ИРБИСа в уже свою библиотеку) я в целом решил с помощью другого Кирилла, там схема такая: yazproxy цепляется к Z64 чтобы предоставить записи ИРБИСа как SRU-сервер. Дальше остается кидать в SRU-сервер поисковые запросы, получать ответы и синхронизовать метаданные.

вы имеете ввиду Колосова? он тоже с молчанку играет... часто...


Лучше бы, конечно, ИРБИС обзавелся сам OAI-PMH провайдером, но видимо это все настолько редко востребованно, что разработчикам такую штуку созидать не интересно. Отрасль не доросла ))


отрасль давно доросла... протокол востребованный при работе с разными платформами...

И levr упомянул способ импорта аналитики. Вот тут я не слушал чтобы кто-то у нас в стране аналитику (скачивание, просмотры и всякие там подобные метрики) как-то стандартизованно хранил и тем более экспортировал/импортировал.

вот это я не понял... поподробнее... как это НИКТО с аналитикой не работает? скачивание, импорт/экспорт и т.д.... а корпоративная работа по росписи аналитики?

levr написал(а):
-------------------------------------------------------

> вот это я не понял... поподробнее... как это НИКТО
> с аналитикой не работает? скачивание,
> импорт/экспорт и т.д.... а корпоративная работа по
> росписи аналитики?

Стандартизованный способ - это когда статистику из разных систем можно автоматически свести воедино и чтобы статистические характеристики там понимались однозначно. Т.е. стандартизован сбор статистики и ее представление в виде xml или еще как-то.

Условно говоря, когда один и тотже человек в понедельник и во вторник прочитал одну и туже книгу в OJS - это одна книговыдача или две?

Если в одной системе, скажем в OJS, человек читая статью, фактически открывает ее в браузере как pdf-файл (т.е. происходит его скачивание), а в другой системе этой же организации веб-плеер (пусть будет ИРБИС) показывает книгу по одной странице и человек пролистал там две страницы из 10, то как потом суммировать эти просмотры?
Первая система не знает сколько человек страниц прочитал, она вообще зафиксировала скачивание, а вторая система (допустим) знает что человек не нажимал кнопки "скачать", а просто просмотрел две страницы, то как вы будете сводить воедино эти данные?

Тоже самое с сессиями. Одни системы считают что сессия прервана если не было 30 минут активности, другие прерывают сессию раз в сутки, третьи сессии считают не опираясь на куки, а по ip-адресам. А теперь еще немного усложним, и добавим еще обращения с мобильных приложений у которых вообще кук никаких нет и обращаются они по API и по ip-адресам сессии считать нельзя т.к. при подключении по wi-fi эти адреса даже у одного устройства могут менять по несколько раз на дню.

Ну и как потом складывать сессии из разных систем, если они все посчитаны по разной методике?

мы наверное немного про РАЗНОЕ говорим.... меня интересует ОЧЕНЬ конкретная функция, которая должна быть доступна БИБЛИОТЕКАРЮ, может по авторизации в редакции журнала, который ГОТОВИТ свой журнал на OJS.. т.е. этот библиотекарь, должен иметь возможность или по электронной почте (но чтобы редактору экспорт можно было удобно сделать), или скачать, из какой-то точки в сети, куда их положат из редакции, или по протоколу прямо из среды своей АБИС получить библиографические записи на аналитические описания статей из журнала в .xml- формате с метками MARC21... если бы он в ИРБИС дам с текстовом формате с метками MARC21.. было бы лучше :).. а как считать статистику будет OJS?... так это его проблемы :).. какие ПРАВИЛА для себя напишет, на основе международных и ГОСУДАРСТВЕННЫХ стандартов.. так и будет считать... за соблюдение госстандартов в области статистики в библиотечном деле ему зарплату платят...

Тогда наиболее правильным будет спросить, есть ли у кого OAI-PMH харвестер, который сможет выплевывать собранные метаданные в формате, годном для импорта в ИРБИС.

Ну и да, очень может быть, что в elpub сами сделали нужный модуль.