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

А если зайти совсем с другого конца и посмотреть на wordpress с соответствующей темкой и плагинами для просмотра? Правда описательные и структурные возможности там не так хороши.

Требуется помимо оболочки представления контента иметь инструментарий для мета-описания документов. Смотрю в сторону ResCarta, пока нравится идеология.

Держите в курсе, интересно. Сам я кроме друпал-библио и вордпресса с описанием на уровне микродаты от schema.org+рубрики+метки ничего не делал, но интересно.

P.S. Друпал библио не осилил :(

Нашел статью Музей як соціокультурний інститут в умовах інформаційного суспільства. Правда на украинском, но здесь можно увидеть другое ПО кроме Камиса.

Кстати, мне тут вспомнилось на OR2014 бразильцы презентовали какую-то надстройку над DSPACE для виртуального гербария. Хотя чисто технически это были сканы листочков. Помню смутно, но выглядело прилично.

A Digital Repository for the Herbarium Collection of Brasília Botanical Garden

презенташку поищу

На мой взгляд, вполне логично рассматривать ИРБИС, как инструмент, на первом этапе, для создания БД для учета и описания оцифрованных фотообъектов (951) для выставок, а далее экспортируйте, куда хотите и объект с его DOI, и его описание, и в Дублинском ядре, и в MARC-форматах! Если перефразировать одного известного :) политика, 20 века "Автоматизация - это учет и контроль!" :)

С таким же успехом можно рассматривать и MS Access или Excel. Но если ИРБИС знают только библиотекари, то продукты от Microsoft знают и обычные пользователи.

Требование метаописания (библиографического, надо полагать) - довольно жесткое требование. ResCarta - очень даже может быть.

Из того что приходит в голову и не ResCarta действительно можно на Drupal наколхозить. Основной минус - выглядеть будет не очень ). Пользоваться при этом Drupal Biblio или самому нужные поля с помощью CCK добавить - зависит от задачи.

Еще возможный к рассмотрению вариант: метаописание держать в Ирбисе, а фото на чем-то, где красиво выглядеть будет (Drupal, Wordpress, Joomla!, etc).

____________________
[elibsystem.ru]

Omeka (GNU/GPL)
Идеология сравнима с DSpace, но попроще.

Omeka - насколько могу разуметь, универсальная платформа "designed for scholars, museums, libraries, archives, and enthusiasts". В отличие от научного репозитария (архива).

Есть где посмотреть на фото в Omeka?

Пример использования Dspace для этих целей.
[earchives.bsu.by]
Гы :)

[195.74.82.67] - тут скорее превьюшки.

Блин, буквально недавно на какой-то конференции или вебинаре рассказывали про омеку, но на вскидку не помню...

[www.virginiamemory.com] - уютненький пример
[www.bacarchive.org.uk] - альтернативно уютненький пример в духе тумблера
[www.floridamemory.com] - классика...

А белорусы просто разгоняют домен... всеми доступными способами. Кстати, большие фоточки доступны по ORE ;)



Редактировано 2 раз. Последний раз 23.01.2017 21:39 пользователем IdeaFix.

[www.virginiamemory.com] - на письма заточено. Для фото, ИМХО, не сильно удобно. Да и для писем не очень удобно.

[www.bacarchive.org.uk] - это уже удобней. Что не нравится - метаданные давлеют над фото. Т.е. метаданным при просмотре уделено центральное внимание. Может так и задумано... не берусь судить.

[www.floridamemory.com] - вот интересная штука. Особенно впечатлила продажа флоридской библиотекой фотографий по 10$ за штуку -). Хорошая вещь! Надо внедрять!

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

З.Ы.: ORE - энто что такое?

С БГУ я понимаю, что прокачка домена - дело благородное. Но Челябинские мужики и то не настолько суровы в выборе инструмента.

OAI-ORE - [www.openarchives.org] т.е. PMH для метаданных, а ORE дя данных.

Ну а что касается внешнего вида омеки - тут всё упирается в то, на сколько силён их css3 :)

OAI-ORE похож на аналог FRBR/RDA.

Едва ли...

А, ну да, агрегаты описывает.
Но таки тогда не для данных, а некое описание коллекций.

Omeka покажется более гибкой по сравнению с DSpace, бо написана на php, а не на java. Сейчас и библиотекари есть, которые знают php, css, js.

Могу лишь пожелать успехов тем библиотекарям, которые админят большие песочницы на php :)

Кстати, pkp (не путать с php) видимо не в тренде, раз приколотили solr к ojs.

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

А то, что в мире нет живых специалистов по apache cocoon, это просто так звезды встали. Ява тут не при чем.



Редактировано 1 раз. Последний раз 24.01.2017 21:45 пользователем IdeaFix.

О! Холивар!

Хочу библиотеку под фото с нормальным бибописанием, библиотечными интерфейсами и на java. Какой артефакт из мавен-репозитария ставить?) З.Ы. Dspace не предлагать -).

Для относительно несложных приложений легкие в изучении php-фреймворки весьма хороши. И работают часто быстрее такой клевой java (хотя тут когда как). И в разработке дешевле.

А то, что у кого-то неудачный опыт с OJS, ну так и на Java можно что-то неимоверно-сложное создать в поддержке и модификации. Я бы даже сказал, что на Java что-то сложное в понимании создать будет гораздо легче -). Особенно, если готовыми фреймворками не пользоваться, а прямо так в JSP и ваять все.

Почему OJS выставляются претензии по поводу выбора Solr к качестве поиска я не очень понимаю. А на чем его надо было делать? На stateless-языке php? А ничего, что это stateless язык by design? Он не предназначен для создания демонов.

Собственно, опенсорсных поисковиков три: Solr, Elastic, Sphinx. Последний как раз в начале карьеры очень php-ники любили за php-модуль с поисковым интерфейсом. Sphinx и сейчас любят. За скорость и непрожорливость по памяти.

Имхо, Omeka будет дешевле кастомизовать Dspace-а. Во многом за счет использования Zend Framework в основе. Указанные примеры, скорее всего, и есть кастомизации, а не просто приаттаченные CSS-файлы.

Кстати, встречайте php vs. java на примере библиотеки.

[elibsystem.ru]

Xerox - чистая Java. Не удивлюсь, если и PDFBox там же используется. НЭБ, ELiS - php. Про то, что Xerox DocuShare может одну книгу по 30 секунд открывать и возблагодарить за это надо именно работу с PDF-библиотекой - я даже упоминать не буду, ибо дело не в языке, а в пальцах рук -).

Большинство отечественных ЭБС, кстати, работают на php. На java работает всего одна.

Omeka заточена под хостинг на основе Linux. Сейчас играюсь: тест проверки правильности пути InageMagick не проходит (баг), но зато делает thumbnails добавленных файлов/изображений. Пока нравиться.

Цитата:

Могу лишь пожелать успехов тем библиотекарям, которые админят большие песочницы на php :)

Под библиотекарем понимал инженера-программиста, который работает в штате библиотеки.

На сколько я понимаю, опыта работы с java в целом и базовыми, использующимися в 146% проектов решениями на базе стандартных мавеновских библиотек, и того же imagemagick у Вас нет, но почему-то есть устойчивое мнение насчёт этого :) Это странно.

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

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

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

Хорошее сравнение ). Мне нравится -).

Но там вообще и ссылки есть, и методика описана, так что можете провести и сами все проверить. Может быть свое что-нибудь добавите на pdfbox (из мавен-репозитария :) ). Или вообще что-то свое проверите.

Рассказываю как бы я извлек "полные тексты" из PDF на php:

<php
`pdftotext file.pdf file.txt`;
?>

Вот, как-то так :)


А на основании чего вы поняли, что опыта работы с java и imagemagick у меня нет?)

Но как дилетант профессионалу, хочу высказать ценное наблюдение: что-то эти джависты уже много лет переползают то на Scala, то на Groovy, то на Kotlin. Называют их даже Java.next. Хотя от Java там только то, что они поверх JVM работают. И мавен что-то у обожальщиков Java не впочете в последнее время. После выхода Gradle.

Ну а подогнать запрошенное решение (тему топика) из мавен-репозитария, я понимаю, вы отказались. Увы. Не все могут мавенисты :(

Брать на слабо тут не стоит :)

Решение не моё, но всё же

[elib.uraic.ru]

Полный текст и оглавление извлечены посредством pdfbox, файлы есть размером один гигабайт и более, pdftotext в данной ситуации ведет себя вполне предсказуемо.

Ну а как извлекать превьюшуи - это вопрос вкуса. Dspace в определённых версиях имеет 4 способа на выбор, хотя вроде и сейчас 4, xpdf не оторвали, просто екомендовали не использовать ибо не тестировали.

Не я призвал сравнивать Dspace и ELiS в данной ветке. Но раз пошло, то давайте сравним на примере предложенной IdeaFix книге.

На правой стороне ринга:

Dspace, Java, Solr, PDFBox и книга [elib.uraic.ru]

На левой стороне ринга:

ELiS, PHP, Sphinx, прочие технологии и снова эта же книга [demo.elibsystem.ru]

Оглавление

Посмотрим на оглавление. О боже! Оно одинаковое у обоих спортсменов! У ELiS оно в левом верхнем углу, не пропустите -). Что происходит при клике по теме в оглавлении?

Dspace запускает скачивание ресурса с использованием нестандартизированного значения в URL page=N (оно нигде не стандартизовано, просто это параметр, позволяющий открыть PDF на нужной странице в ActiveX плагине Adobe Reader. Затем аналогичное решение реализовали производители PDF-плееров в Chrome и Mozilla). Стоп! Я сказал Chrome и Mozilla? А какой же я браузер не назвал? Бедный-бедный Internet Explorer :( и за что его так?

Посмотрим на ELiS: при клике на тему в оглавлении происходит переход на нужную страницу вместо запуска процедуры скачивания всего файла. Действительно, зачем качать 1 ГБ файл, если в среднем пользователи читают 5-10 страниц, расходуя на это ну пусть 5-10 МБ трафика?

Поиск

IdeaFix намекает нам, что Solr рулит и всех рвет, а остальные - так, отстой. И pdftotext тоже отстой (а текст ведь мы извлекаем именно чтобы найти его). И PHP - отстой. (И коза у него - дура!)

Ну что же, сравниваем!

Будем искать слово "Анафемсшй" со 152 страницы.

Dspace нашел: [elib.uraic.ru] но кликая по результату мы переходим почему-то не к странице с Анафемсший, и даже не к скачиванию книги, а к описанию книги. Позвольте, а как я узнаю, что нужное слово на 152 странице? Никак? И хваленый Solr, PDFBox извлекающий текст заведомо лучше pdftotext мне здесь не помогут? Но как же так? Они же такие прям клевые? А я понял! ELiS то тогда точно ничего не найдет! Она то хуже во всех используемых технологиях! Смотрим!

ELiS, на базе Sphinx и pdftotext, как это ни пичально для IdeaFix, нашла слово: [demo.elibsystem.ru] . И что будет, если кликнуть на результат? О чудо! Открылась сразу 152 страница!

Скорость работы
Меня тут чуть выше тролили в бенчмарке скорости -). Грех не закончить обед ужином, поэтому поедим еще раз -)

Открываем 152 страницу (почистив кеш браузера, конечно!), типа мы перешли из оглавления.

Dspace: [elib.uraic.ru]
39 секунд! [user.files.psu.ru]

ELiS: [demo.elibsystem.ru]
4 секунды [user.files.psu.ru]

Разница в 10 раз!

Статистика
Внимательный читатель может вдруг спросить - а с какой стати я взял, что средний читатель смотрит 5-10 страниц и уходит?

А я скажу: раз плеер документа мой, а не встроенный в браузеры, то я могу посчитать сколько страниц пользователь реально просмотрел. И оно, увы и ах, действительно такое. А раз статистика считается из плеера, то в нее не попадают всякие кешированные страницы и т.п. вещи, искажающие статистику при подсчете ее из логов веб-сервера. При этом событие открытия книги (и просмотра страниц) и события скачивания на ПК - это разные события. Подробности: [elibsystem.ru]

В приведенном примере с Dspace хотя книги и открываются в браузере, из-за особенностей работы встроенных в браузер PDF-плееров и подхода Dspace - все есть поток байтов (bitestream), подсчитать страницевыдачу без довольно серьезных надстроек над Dspace не представляется возможным. Собственно, она и не считается.

Таким образом, в статистике по книге Dspace говорит только факт открытия книги, тогда как ELiS рассказывает еще и насколько внимательно открывший ее читал.

Можно еще по многим пунктам продолжать, просто не понятно зачем -), если у одного из сравниваемых решений есть фатальный недостаток: не "содержит в названии ELiS" =) А так да: Java, Solr, PDFBox лучше PHP, Sphinx, ... -)



Редактировано 1 раз. Последний раз 25.01.2017 20:24 пользователем borovinskiy.