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

Да ну? Т.е. я могу взять код под GPL, модифицировать его и начать про-да-вать? В общем да, могу. Более того, я не обязан контрибутить, но обязан предоставить свои изменения по первому требованию, а гарантии того. чтоя предоставлю код, я должен предоставить и вовсе без требований. Собственно, где гарантии от неикона?



Редактировано 1 раз. Последний раз 08.02.2016 08:34 пользователем IdeaFix.

«Экспорт/Регистрация в CrossRef»: Этот экспортирует или регистрирует метаданные статьи в формате CrossRef.
«Экспорт/регистрация DataCite»: Этот позволяет экспортировать или зарегистрировать метаданные выпуска, статьи, гранки и дополнительных файлов в формате DataCite.
«Экспорт в DOAJ»: Этот позволяет экспортировать журнал для DOAJ и предоставить информацию о журнале для добавления в DOAJ
«Импорт/экспорт DuraCloud»: Этот позволяет архивировать и восстанавливать выпуски, используя для хранения внешнюю службу DuraCloud
«Экспорт статей в формате Erudit»: Этот экспортирует статьи используя английскую версию DTD Erudit.
«Экспорт/регистрация mEDRA»: Этот экспортирует метаданные выпуска, статьи и гранки в формат Onix for DOI (O4DOI) и регистрирует DOI в регистрационном агентстве mEDRA.
«Экспорт в METS XML»: Этот экспортирует журналы в METS XML
«Статьи и выпуски в XML»: Этот импортирует и экспортирует статьи и выпуски
«Экспорт в PubMed XML»: Этот экспортирует метаданные статей в формате PubMed XML для индексирования в MEDLINE.

Вот это есть и почти работает из коробки. ну а то, что ирбис работает только с marcxml, который сделан этим же самым ирбисом - это проблема ирбиса. И если уж пилить разработчиков, я бы не за OAI пилил, а за Rest API.

В DOAJ и Scopus с PUBMED шлём XML'ку, а в ирбис онлайн синхронизация?:) не будет этого. К тому же, посмотрите на чистоту метаданных в том же elpub или в украинском ресурсе, она на уровне местечковой библиотеки. Нельзя из таких систем онлайн импорт делать.



Редактировано 2 раз. Последний раз 08.02.2016 08:05 пользователем IdeaFix.

IdeaFix написал(а):
-------------------------------------------------------
> borovinskiy
> > elpub лицензию GPL не нарушает. Обычная GPL
> > вообще не работает пока человек не начинает
> > распространять работу.
>
> Да ну? Т.е. я могу взять код под GPL,
> модифицировать его и начать про-да-вать? В общем
> да, могу. Более того, я не обязан контрибутить, но
> обязан предоставить свои изменения по первому
> требованию, а гарантии того. чтоя предоставлю
> код, я должен предоставить и вовсе без требований.
> Собственно, где гарантии от неикона?


А там разве сборка OJS продается? Там аренда сервиса, код, на сколько я понимаю, в руки не выдается. Нет выдачи кода в виде сборки - нет распространения.

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

Разъяснения о SaaS есть :) Человек, заинтересованный в коде из числа клиентов тоже есть. Так же есть слегка странное поведение первой линии поддержки elpub в ответ на звучащие от пользователей вопросы. Но, мне эта тема в общем не очень интересна. Просто редактор задал вопрос, что будет если он в колонке редактора потребует... предложил ему не быть клоуном, редактор согласился.

Пробовал я экспортировать из ИРБИСа в DSpace. Что в OJS, что в DSpace один формат данных, поэтому можно утверждать, что будет работать и для OJS, по крайней мере, на уровне метаданных. Но MARC и DC (стандартный набор) несовместимы между собой. Вернее нет, полной совместимости. Т. е. если из DC в MARC можно кинуть абсолютно все из коробки, то обратно уже нет. Пример экспорта можно посмотреть по ссылке Пример. Но это все допиливалось: сохранялось в csv формат, а не xml.

woodyfon
Гугл любит миметайп...

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

Есть вариант работать с плоским CSV, всё реально работает если схема стабильна - не хтим, нет одной кнопки, ат рууками это 10 кликов а не один.

Есть вариант работать с REST, правда придётся написать форнтэнд с зеленой кнопкой - хотим. но пусть напишет кто-нибудь другой.

Здесь все айтишники-автоматизаторы, а "большая зеленая кнопка" - это для библиотекарей, и первые не особо любят что-то делать

woodyfon

В примере съелся текст в кавычках.
[er.knutd.com.ua]

local.source: Вісник Київського національного університету технологій та дизайну. Серія ????????

Спасибо, что указали на ошибку. Формат csv-файла такой, что содержимое в двойных кавычках есть данные. Поэтому, если необходимо импортировать информацию в кавычках, то приходится дополнительно дописывать двойные кавычки. Функцию замещения не включил в формат печати записей из ИРБИС.
Будет массив для пакетного редактирования записей.
+
Исправлено с помощью пакетной корректировки.
P. S. Хм... аналог глобальной корректировки в IRBIS, но работает только через Replace или Add.
В DSpace стоит ограничение на максимальное количество корректируемых записей через UI (20). Расширяется в файле [dspace]/config/modules/bulkedit.cfg. Параметр gui-item-limit. Здесь же можно имзенить символы разделителя полей, повторений, данных в авторитетных файлах. Подняв значение до 100 не заметил каких-либо "торомозов" или подвисаний. Наверное, введен с целью обезопасить пользователя не наделать много ошибок сразу. Но после пакетной правки всегда проверяется полученный результат. Интересно, почему???



Редактировано 1 раз. Последний раз 10.02.2016 13:31 пользователем woodyfon.

Имели опыт увеличения до 500, а в консоли (dspace metadata-import) и вовсе тысячасми загоняли.

IdeaFix:

А какие недостатки вы видите в использовании OJS в качестве сайта вузовского журнала?

Если у редакции нет проблем с работой в формате электронной редакции - практически никаких. Если есть - это двойная работа. Работали как раньше + полный цикл на сайте.

Если придираться к технической части:

1. Общий легкий бардак в системе. Начинаешь это понимать, когда берешь эту CMS на поддержку после чего-то более стабильного.
2. Не полная "многоязыкость" интерфейса, например, нельзя написать синоним фамилии редактора на русском и английском языках и чтобы вариант написания менялся в зависимости от выбранного языка интерфейса сайта. Так же нет автоопределения языка пользователя и коробки (правится в один яваскрипт) и пр. мелочи.

Т.е. я бы разделил проблемы на три вида:

1. Идеологические - проблемы внутри живых людей в редакции. Они не разрешимы. Мы пробовали менять систему - ничего не улучшается. А вот если менять людей - становится лучше :)
2. Архитектурные - сложные проблемы на уровне ядра CMS - они в общем с ходом времени решаются разработчиками.
3. Мелочи - решаются толковым админом.

IdeaFix написал(а):
-------------------------------------------------------
> А вот если менять людей - становится лучше :)

Итого, сколько редакций использует OJS по назначению?)

У нас не много. Треть где-то. Причем чем журнал старше, чем он более классический, тем сложнее.

А если говорить о HOSTED решениях, типа elpub и пр - там и того меньше. Там реально "сайт журнала".

[www.zone-h.org]

лечимся...

Эм. Какой-то новый международный рейтинг? Что сделать надо чтоб в него попасть? :)

borovinskiy
Надо иметь старый-старый пхп... желательно 5.4.20 и ниже... :) Просто среди призёров и победителей очень много старых инсталляций ojs.

Я вот заменил старый-старый пхп на не очень старый. При замене на не старый что-то отпадает и перестаёт работать проверялка референсов в кроссрефе, и может быть что-то еще... так что - не очень старый пхп - наш выбор!



Редактировано 2 раз. Последний раз 22.06.2017 20:05 пользователем IdeaFix.

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

У нас был опыт, использовали видоизмененный импорт/экспорт стандартный. Видоизменяли на предмет референсов. Стандартный плагин в 2.4.х не умеет референсы, в 3.х не знаю.

Когд не мой, писали коллеги, поэтому не могу передать. По сути там XSL трансформер из РИНЦ XML в формат OJS

Параметры настройки PHP, на которые стоит обратить внимание:

allow_url_fopen = On
allow_url_include = On
post_max_size = 64M
upload_max_filesize = 64M

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

Эхх... у нас гранки по 4ГБ есть :) Да и авторы порой чудят при загрузке рукописей...

Я импортировал. В ирбисе32 делал печатную форму, которая создает нужный xml с самим документом. Единственная загвоздка была в кодировке выходного файла. Правда, если мне память не изменяет, я немного правил модуль импорта

не важно кто ты, библиотекарь-автоматизатор, админ или программист, рано или поздно придётся написать свой первый xslt :)

При тестировании импорта обнаружил, что в OJS 2.4.8.2 в метаданных для авторов нет локализованного варианта так это сделано для названий.
Понимаю, что из OJS экспортируются выпуски и отсылаются, например, в CrossRef. Последний очень любит Latin.
Но как быть со старыми статьями, где нет латиницей фамилий и имен авторов?
А отсебятину делать не хочется.

В 2.4.x из коробки у автора просто не может быть синонимов. В 3.х этой проблемы нет, в 2.4.х все решения данной проблемы что я видел, генерируют новые проблемы. Например в elpub долгое время был сломан OAI (работал только oai_dc) и наверняка многие другие стандартные инструменты из-за изменения структуры метаданных.

Обнаружил при импорте, если одна секция имеет название, к примеру, "Проблеми економіки організацій та управління підприємствами", а другая "Проблеми економіки організацій та управління" получаем ошибку типа дубликат ключа в БД. Баг или особенность - не знаю.

... Чем дальше тестирую, тем больше напильник нужен.

А я предупреждал... OJS - он такой :) И если с dspace можно пожевать-пожевать кактус и остановиться в какой-то момент и всё будет работать, то с OJS жевать кактус и плакать приходится всегда...

Кстати, у Вас поиск без проблем работает?

До поиска пока не дошел толком. Но из коробки отказывался работать поиск для конкретного журнала. Пришлось подправить код в php-файле. Сейчас вроде как работает, но основательно его пока не тестил.

Там основная проблема в SOLR/JETTY, а не в SMARTY.

Цитата:

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

Ну пожалуй да, время подтвердило, что так оно и есть.