Як працюють контрольовані словники?

Щоб забезпечити точні результати пошуку та коректне відображення даних, museum-digital використовує нормалізовані дані — контрольовану термінологію. Для їх управління розроблено багатомовний інструмент nodac, який контролює словники museum-digital і може застосовуватися для роботи із зовнішніми термінологіями.

Деякі контрольовані словники безпосередньо пов’язані з введенням і виведенням даних у museum-digital. Ці словники, разом з іншими термінами, доступними через nodac, відкриті для загального використання через веб-інтерфейс та API md:term.

Додавання нових термінів відбувається автоматично: якщо один музей вводить нове поняття, воно стає доступним для всіх. Це дозволяє спільно розвивати наукову лексику для опису колекцій.

Гнучкість у використанні географічних назв

У museum-digital надається перевага сучасним географічним назвам, але система дозволяє враховувати й історичні варіанти. Деякі музеї фіксують історичну назву місця виготовлення предмета, інші — сучасну. Обидва підходи підтримуються, оскільки назви прив’язані до єдиної системи синонімів. Наприклад, пошук за запитом «Львів» також видасть результати для Lwów та Lemberg.

Рекомендується використовувати сучасні назви без політичних позначень, якщо це не є принципово важливим для об’єкта. Наприклад, просто «Київ», а не «Київ, Українська Народна Республіка». Датування об’єкта допоможе точніше визначити його історичний контекст.

Важливо: у системі існує окрема категорія «історичних» місць. До неї входять лише населені пункти, які більше не існують (наприклад, шахтарські селища, що зникли через видобуток корисних копалин). Якщо місто просто змінило назву, але продовжує існувати, воно не вважається історичним.

Як правильно вводити географічні назви

Щоб правильно пов’язати новий об’єкт з уже існуючими даними, рекомендується вводити назву без зайвих слів. Наприклад, «Київ», а не «місто Київ».

• Не додавайте службові слова на кшталт «місто», «село», «селище». Наприклад, «Мезин», а не «с. Мезин» чи «село Мезин».
• Використовуйте службові слова, якщо вони є частиною офіційної назви. Наприклад, «Київська область», «Новгород-Сіверський район», але просто «Дніпро».
• Якщо населений пункт має поширену назву, можна навести курсор на запропоновані системою варіанти та вибрати потрібний район/регіон.

Як додати нову назву, якщо її немає у словниках?

Контрольовані словники постійно оновлюються, але якщо потрібної назви немає, її можна додати вручну.

1. Введіть назву населеного пункту у відповідне поле.
2. Натисніть «Надіслати» або Enter.
3. Відкриється меню внесення нової назви.

Рекомендується уникати службових слів (наприклад, «село», «селище») — їх краще вказати в описі. У цьому ж розділі можна додати інформацію про район, область, країну.

Ми сподіваємося, що ці рекомендації допоможуть вам правильно використовувати контрольовані словники museum-digital, полегшать пошук та внесення нових даних, а також сприятимуть точному й узгодженому опису колекцій. Якщо у вас виникнуть запитання або зауваження, звертайтеся до підтримки museum-digital Ukraine (ukraine@museum-digital.de).

До всіх цих об’єктів можна отримати доступ і шукати разом через museum-digital:global.

У цій статті ми поговоримо про структуру даних інформації щодо об’єкта, з якою працює museum-digital. Розуміння цієї теми дасть Вам змогу вибудовувати свою базу даних об’єктів послідовною та акуратною, а також забезпечить актуальність Ваших даних на багато років.

Відправною точкою структури museum-digital є (музейний) предмет. Що вважати окремим предметом, залежить від конкретного музею. Традиції класифікації вельми різні: в одних музеях зображення і рама реєструються окремо, в інших вони розглядаються як єдине ціле. Усі музейні об’єкти, однак, мають одну очевидну властивість – з ними відбувалися якісь події, які фіксують їхню історію. Розберемося детально як такі події реєструються в museum-digital.

Museum-digital розрізняє близько 50 можливих дій з об’єктом, тобто ЩО сталося з об’єктом. ХТО – ДЕ – КОЛИ фіксуються в категоріях: дійові особи (актори), місця, часи. Крім цього, до об’єкта можуть бути віднесені ключові слова, які не відображаються в ЩО – ХТО – ДЕ – КОЛИ. Але вони все одно містять важливу інформацію щодо предмета і допомагають оперативно знайти його в базі даних. У випадку зі щоденником Анни Франк ключові слова можуть бути: щоденник, Переслідування в період націонал-соціалізму, Друга світова війна, тощо.

При цьому кожен об’єкт може бути пов’язаний з будь-якою кількістю подій. Візьмемо, наприклад, щоденник Анни Франк. Записник купив, а потім подарував Анні Франк її батько 12 червня 1942 року. Потім Анна Франк володіла книжкою і робила в ній записи аж до її арешту і депортації в табір Берген-Бельзен. Пізніше книга належала Міп Гіз, а потім батькові Анни Франк – Отто Франку. Зараз щоденник зберігається в Будинку Музеї Анни Франк в Амстердамі на Прінсенграхт 263-265. При цьому будь-яке перевидання щоденника у вигляді книжки тією чи іншою мовою, зрозуміло, вважатиметься абсолютно іншим типом предмета і матиме зовсім інші пов’язані з собою події. Але в кожного об’єкта все одно будуть свої ЩО – ХТО – ДЕ – КОЛИ.

У museum-digital ці 4 категорії – дійові особи (актори), місця, часи, ключові слова (теги) відображаються в контрольованих словниках. Введення понять до контрольованих словників відбувається автоматично: якщо один музей ввів якесь поняття, воно одразу ж доступне всім музеям у системі. Усі словники доступні на порталі md:term. Про керування словниками можна прочитати на інформаційному сайті md. Якщо коротко: будь-який користувач може їх редагувати в рамках роботи над своїми об’єктами, редактори nodac займаються модерацією. Завдяки спільній роботі над контрольованими словниками, музеї підтримують один одного в розробці спільного наукового лексикону для опису своїх зібрань.

Тепер настав час розібратися, як фіксувати ці типи даних у museum-digital коректно і послідовно. Усі типи подій можна переглянути і вивчити під час їхнього створення, тому ми не будемо концентруватися на цьому. Нам належить поговорити про чотири категорії: Місця, дійові особи, часи та ключові слова, які ці події складають.

Дійові особи – ХТО

1. Дійові особи або актори – це виробники, власники, автори, … об’єктів. Це особи або організації, які мають відношення (описуване подією) до об’єкта. У museum-digital актор реєструється як окрема сутність (тобто незалежно від об’єктів або відносин). Один і той самий актор може бути пов’язаний з багатьма об’єктами через безліч подій.
2. “Дійовими особами” в подіях є особи або об’єкти, що індивідуалізуються. Якщо особа, яка перебуває в певному відношенні до об’єкта, не індивідуалізована (наприклад, окрім імені “Олексій Мельник”, яке часто трапляється, нічого не відомо), то цю особу та її відношення до об’єкта не можна зафіксувати в подіях. У такому випадку як місце запису пропонується відповідний опис об’єкта. Зазначення виробника як “Ткаченко” або “О. Кравченко”, а також “Олексій Мельник”, не розширене нічим (наприклад, відсутні рік народження і смерті, опис особистості та все інше, що характеризує конкретну людину), призводить до того, що дві різні людини з таким ім’ям не можуть бути відокремлені одна від одної в базі даних. Стає незрозуміло, який “Олексій Мельник” має вважатися виробником конкретного об’єкта.
3. Для “первинної індивідуалізації” часто, але не завжди, достатньо назви посади або вказівки виду діяльності: “Олексій Мельник (тесля)”. Така інформація (додавання омонімів) потім додається до прізвища в круглих дужках. Якщо є достатньо іншої інформації (рік народження, рік смерті, опис) або якщо саме прізвище не дуже поширене, такі додатки не слід використовувати.
4. Загальні офіційні або професійні титули, такі як “мер”, не можуть бути індивідуалізовані і тому не можуть бути записані як дійова особа. Такі вищі найменування, як “хімічна промисловість” або “виробник паперу”, також не можуть бути використані як дійові особи: вони не можуть бути індивідуалізовані та не є корпоративними структурами.
5. Такі іменні афікси, як “єпископ”, “князь”, “барон” тощо, також можуть використовуватися як афікси омонімів, але опускаються як частина імені. Приклад: “Князь Ярослав Мудрий” не допускається і стає “Ярослав Мудрий”. Якщо ж таких людей кілька, і тільки один із них заслужив шляхетський титул, то його можна назвати “Ярослав Мудрий (князь)” (тобто з додаванням омоніма). Академічні титули, як правило, опускаються.
6. Імена акторів можуть бути задані редакцією як синоніми. Під час пошуку актора з ім’ям у певній формі буде знайдено також об’єкти, з якими цей самий актор пов’язаний у синонімічній формі імені. Наприклад: Ярослав Володимирович Мудрий = Ярослав Мудрий.
7. Актори можуть бути прив’язані до події (яка, зі свого боку, прив’язана до об’єкта), але можуть мати і загальне відношення до об’єкта. За можливості слід обирати прив’язку через подію, оскільки в такий спосіб фіксується характер відносин між об’єктом і актором. Наприклад, якщо об’єктом є лист від людини А до людини Б, у якому згадується людина С, то слід сформувати три події: “Написано – людина А”, “Отримано – людина Б”, “Згадувалося – людина С”. При цьому, події, за можливості, слід доповнювати інформацією про час і місце.
8. Належність суб’єкта до події, а також (загальна) належність суб’єкта до об’єкта може бути або ” визначеною” або “невизначеною”. Якщо впевненості у визначеності немає, не слід вносити в поле введення додаткових символів або слів, достатньо лише встановлення символу [~] замість [≡] в картці дії.

Дійові особи класифікуються в museum-digital відповідно до сутнісного кодування GND, тобто відносяться, наприклад, до “KIF Companies” або “PIK Reigning Princes, Members of Reigning Princes Houses” або “PXL Literary Figures, Legendary Figures” або …. . Існує 8 класів сутностей і ще 8 класів осіб.

Інформація про “суб’єктів” зберігається в каталозі “персони-інститути”, редагується і збагачується покликаннями на сховища стандартних даних (здебільшого доступних як Linked Open Data – LOD). Таке збагачення можливе тільки для персоніфікованих осіб і корпорацій. У частині збагачення і форм назв museum-digital багато в чому наслідує стандарти, прийняті в бібліотечному світі.

Місця – ДЕ

1. Загалом museum-digital віддає перевагу сучасним географічним назвам. Однак і тут діє правило гнучкості – деякі музеї вказують для предмета у своїй базі даних назву місця виробництва на момент виготовлення предмета, інші музеї вказують сучасну форму назви відповідного місця. museum-digital може працювати і з тим, і з іншим, назви місць задаються синонімічно. Якщо ви шукаєте предмети, виготовлені у Львові, ви також знайдете предмети, де як місце виготовлення вказані Lwów, Lemberg – і навпаки.
2. Місце розуміється не як населений пункт, а як місце в просторі: можна називати регіони (“Чернігівщина”), а також, якщо відомо, записувати “номери будинків” (наприклад, “Чернігів, вул.Шевченка, будинок 1”).
3. При цьому запис завжди краще починати з найменшого значення населеного пункту. Тобто писати не “Україна, Одеська область, Білгород-Дністровський район, м. Білгород-Дністровський”, а відразу “Білгород-Дністровський”. Завдяки контрольованим словникам museum-digital система вже знає географічну ієрархію міста. Також працює і з селами та, за потреби, назвами вулиць та номерами будинків. Наприклад, сутність “Фрідріхштрассе 76” уже існує в md, і є частиною вулиці Фрідріхштрассе, що є частиною Берліна, що є частиною Німеччини, Центральної Європи і, відтак, Європи загалом. Для введення таких вдосконалених даних, можливо, буде потрібно спочатку ввести це значення в контрольовані словники.
4. У museum-digital дані про місцезнаходження завжди записуються у вигляді координат; кожному місцю розташування присвоюється тип місця розташування. Найменшою одиницею (або типом) “місця” є будівля. Іншими можливими типами “місць” є вулиці, міста, річки, острови, гори.
5. Особливий тип місця називається “історичним”. До нього належать тільки “місця”, які більше не існують (наприклад, ті, що стали результатом видобутку бурого вугілля). Якщо місце змінило свою назву, але залишилося таким, воно не вважається “історичним”.
6. Крім згадки в описі предмета, існує два способи встановлення зв’язків між місцями і предметами в museum-digital. Найкращий спосіб – пов’язати об’єкт із місцем (наприклад, Карлові Вари) через подію (наприклад, подію виробництва). Таким чином, можна легко зазначити, яку роль відіграло місце для об’єкта (у прикладі: місце виробництва). Другий спосіб – це “загальні відносини”. Про те, що мається на увазі, можна зрозуміти за таким прикладом: сувенірна чашка тайванського виробництва, на якій зображено фантастичний краєвид Бад-Пірмонта (без відповідних написів) і яку продають у Ганновері, має лише дуже непевний і загальний стосунок до Бад-Пірмонту.
7. Відношення між місцем і подією (“місце у виробничій події до об’єкта”), а також загальне відношення між місцем і об’єктом (“місце має якесь невизначене відношення до об’єкта”) може бути як “визначеним”, так і “невизначеним”. Можливо, місце було лише ” ймовірно” місцем виробництва? Може, відношення, яке зберігалося як загальне, стосується скоріше іншого місця (у прикладі: можна тільки припустити, що на фантастичному вигляді зображено Бад-Пірмонт)? Для museum-digital існують тільки ці два стани: “визначений” і “невизначений”. Такі тонкощі позначень, як “можливо”, “імовірно”, “напевно”, “найімовірніше”, “скоріше за все”, “здається” тощо, кожен розуміє по-своєму і тому вводить в оману. Для museum-digital завжди діє таке: “невизначено”. Якщо впевненості у визначеності немає, не слід вносити в поле введення додаткових символів чи слів, достатньо лише встановлення символу [~] замість [≡] в картці дії.

Приклад структуризації контрольованих словників: Брониця — село Дрогобицької міської громади, Дрогобицького району Львівської області. Museum-digital уже знає цю інформацію.

Скріншот з nodac: коректне введення назв місць робить внесок у спільну роботу музеїв з розвитку контрольованих словників.

Інформація про місцезнаходження зберігається в центральному каталозі “Географічні будівлі”, відредагована, вибудувана в ієрархію і доповнена покликаннями на сховища даних за міжнародними стандартами ( що доступні як Linked Open Data – LOD).

Час – КОЛИ

Поділ на події та їхні елементи призводить до того, що в museum-digital не існує простого “датування” об’єкта, а є будь-яка кількість “датувань” подій, які приписують об’єкту. Можна датувати “створення шаблону”, “виробництво” або “використання”. Таким чином, інформація про предмет фіксується набагато повніше, ніж у простому (зазвичай такому, що не має додаткових визначень) полі “датування”, яке досі можна зустріти в багатьох базах даних старого зразка.

Вербальні вказівки часу часто бувають оманливими. Такі терміни, як “повоєнний період”, не говорять, після якої війни настав цей період, “бароко” часто сприймається як період, але позначає стиль, що був проявлений у різних регіонах у різний час. Навіть “неоліт” або “епоха третинного періоду” не є однозначними поняттями, оскільки вчені часто перевизначають їхній початок або кінець і все одно розходяться в думках. Museum-digital не є спеціалізованим порталом для будь-якої однієї дисципліни знання, він призначений для вчених усіх спеціальностей, які не надто добре знайомі з часовим словником кожної іншої дисципліни. Він також орієнтований на неспеціалістів. Щоб бути корисним (і зрозумілим) для всіх, необхідні правила роботи з тимчасовими покликаннями.

• Слід уникати використання як часових термінів предметної “часової лексики”. Для того щоб уявити разом речі, які відбулися в один і той самий час, але в абсолютно різних місцях, важливо уникати таких термінів, як “час Мейдзі”, як поняття часу. Речі, які були зроблені у Франції, Мексиці або Єгипті в період, який зазвичай позначається терміном “період Мейдзі” (25.01.1868 – 30.07.1912), мають бути представлені разом із тими, які були зроблені в Японії. На сайті museum-digital “період Мейдзі” вказано як ключове слово, а це означає, що японіку відповідного періоду можна знайти окремо.
• Таким чином, “гарне означення часу” складається здебільшого з цифр і менше з розмежувальних слів, які загалом передають подальший “сенс”. Використання цифр також полегшує переклад часових термінів.
• Існує й інша причина обмежень у формулюванні часових позначень. Система баз даних має ефективно функціонувати і подавати результати пошуку в зручному для сприйняття вигляді, а також давати змогу легко керувати часовими визначеннями. Для такого управління термінами в museum-digital є редактор стандартних даних. Чим менше використовувані тимчасові терміни відхиляються від наведених нижче рекомендацій, тим менше роботи доводиться виконувати редактору стандартних даних. Деякі з наведених нижче рекомендацій відносяться тільки до рекомендованих написань, інші більш точно описують те, що розуміють під часовим терміном у museum-digital (наприклад, позначення епохи стилю в історії мистецтва позначають стиль і, в кінцевому рахунку, не є конкретною одиницею часу). У наступній таблиці також міститься інформація про те, як вводити в museum-digital додаткову інформацію про час (наприклад, для таких доповнень, як “від”, “до”…).

ДОБРЕ І НЕДОБРЕ

Загальне

Написання

Часи “довкола”

А також:

Скріншот із nodac: коректне введення часу забезпечує точну фіксацію і йде на користь багатомовності платформи.

Ключові слова

Ключові слова полегшують пошук предметів. У museum-digital кожному об’єкту може бути присвоєно будь-яку кількість ключових слів, щоб пошук за зібраннями був успішним і оперативним. Ключові слова також підпорядковуються стандартам даних і за можливості опираються на звичайну практику бібліотечної справи.

У museum-digital ключові слова розглядають як позначення концептів, збагачують покликаннями на загальноприйняті словники (GND, AAT, LCSH…), ієрархізують і надають короткий опис. Ієрархізація дає змогу, наприклад, знайти “конячку-гойдалку” під час пошуку “іграшки”.

Для успішного використання ключових слів під час пошуку і пересилання, а також для зведення до мінімуму роботи зі збагачення та ієрархізації слід дотримуватися таких правил:

→ Вдале ключове слово позначає загальне поняття

У museum-digital контрольовані поняття поділяються на чотири різні царини: географічні назви, імена людей або установ, дати та ключові слова. Відповідні записи мають свої властивості – місце не має року народження, а час – координат. Тому важливо не вводити назви місць, осіб і часу як ключові слова. Ключові слова – це позначення загальних концептів. У museum-digital діє таке правило: як ключові слова допускаються тільки загальні терміни (без місць, дійових осіб і часу).

→ Відповідне ключове слово виникає саме по собі

Одне ключове слово, наприклад “арбалет”, може бути поміщено в ієрархію як “тип” “невогнепальної зброї”. Ланцюжок ключових слів типу “арбалет, щит, шолом, обладунки”, навпаки, важко ієрархізувати або пов’язати із записами в загальноприйнятих словниках. У деяких інших системах баз даних, призначених для інвентаризації музейних предметів, ключові слова представлені тільки одним полем. Для коректного імпорту інформації про предмети з таких систем необхідно, щоб у відповідному полі такої системи завжди використовували одні й ті самі роздільники. Для museum-digital діє таке правило: за всяку ціну уникати ланцюжків ключових слів!

→ Хорошим ключовим словом є “однина”

Поняттям у довідниках ключових слів зазвичай присвоюються терміни в однині. Наприклад, якщо музейним експонатом є історична фотографія, на якій зображено три кошики, то слід використовувати ключове слово “кошик”, оскільки це одне й те саме поняття (“Korb”) для всіх кошиків, навіть якщо в цьому разі його було використано тричі. Є кілька понять, що позначають речі, які зазвичай зустрічаються в парі, наприклад, “взуття”. Тільки в цих – небагатьох – випадках форма множини є більш придатною. Щодо museum-digital діє таке – ключові слова (майже завжди) повинні вказуватися в однині.

→ Належне ключове слово – з повсякденної лексики

Ключові слова мають складатися із загальновживаних, повсякденних визначень. Слід уникати “ланцюжків слів”, а краще розділяти їх на окремі ключові слова, якщо це не шкодить концепту загалом, напр: “друга світова війна” пишеться разом.

→ Гарне ключове слово не має ієрархії

Предметний покажчик museum-digital структурований ієрархічно. Знову додані ключові слова вбудовуються в цю ієрархію редакторами стандартних даних. Тому немає необхідності привласнювати об’єкту кілька ключових слів з ієрархічного порядку, наприклад, привласнювати об’єкту, що представляє собою “пару сережок”, як ключові слова і “сережки”, і “прикраси для вух”, і “ювелірні вироби”. Така ієрархія (“сережка” → “прикраси для вух” → “ювелірні вироби”) уже існує в каталозі ключових слів museum-digital і враховується під час пошукових запитів. У museum-digital діє таке правило: як ключове слово завжди слід обирати найвідповідніший термін; у цьому разі слід уникати ієрархічно вищих термінів.

→ Добре ключове слово – не димінутив!

Поняття “кошик”, що позначається ключовим словом, може бути застосовано і до особливо маленького “кошика”, “кошичка”. Слід уникати зменшувально-пестливих слів. З одного боку, важко встановити розмір, за якого “кошик” є “кошиком”, а з іншого боку, маленький кошичок також ґрунтується на понятті “кошик”.

→ Гарне ключове слово – не “-подібний” або “-видний”…

Якщо форма музейного предмета імітує “грушу”, то за дизайном стоїть поняття “груша”, хоча в просторіччі цей предмет може називатися “грушоподібним”. Якщо поверхня дизайнерського стільця із пластику оформлена таким чином, що складається враження, ніби стілець зроблений із дерева, то слід використовувати ключове слово “дерево” (оскільки саме така концепція лежить у його основі), але в жодному разі не “декор під дерево”, “вигляд дерева”, “імітація дерева” або ” вигляду дерева”. У museum-digital застосовується таке: ключові слова позначають безпосередньо пов’язані з ними поняття. Якщо вони є імітацією, то додатково можна використовувати ключове слово “імітація”. (Виняток становлять терміни з біологічних класифікацій, наприклад, “дельфіноподібний” – тут “-подібний” є частиною звичайного іменування поняття).

→ Гарне ключове слово – це іменник

У загальному випадку прикметники (“штампований”, “лакований”, “дірчастий”…) не підходять як ключові слова. Прикметники часто описують додаткові якості (“срібло з клеймом”), і їх краще помістити в загальний опис предмета.  Як варіант, їх можна замінити відповідними іменниками (у прикладі: “клеймо” і “срібло”).

→ Добре слово не знає “зображення/мотив”

Важко встановити єдину думку про те, чи реалізує картина із зображенням мосту поняття “міст”, чи в цьому випадку міст є мотивом, а “міст (зображення)” – самостійним поняттям. Однак, оскільки основоположним поняттям завжди є “міст”, у museum-digital може бути застосовано таке: ключові слова не потребують додавання  слова “(зображення)”.

→ Хороше ключове слово – сучасне

Для ключових слів слід використовувати нове написання (наприклад, проєкт замість проект). Однак, особливо під час імпорту “старих даних” із музейних баз даних, багато визначень часто вводять у базу даних у старому написанні. Їх або замінюють новим написанням або, якщо вони ще дуже поширені, вносять як синоніми нового написання в індекс ключових слів museum-digital. У museum-digital застосовується нова орфографія.

Скріншот із nodac: ключові слова допомагають в управлінні зборами, оскільки кожен тег створює свою міні-групу об’єктів.

Ми сподіваємося, що запропоновані рекомендації сприятимуть систематичному та уніфікованому внесенню інформації до museum-digital. Це, своєю чергою, сприяє стійкості та довгостроковій цінності даних, що має позитивний вплив на всю галузь досліджень і культурної спадщини.

Запис зроблено: ICOM Deutschland e.V.
Переклад українською: Д-р Сергій Ципишев, Зоряна Ципишева

Нижче представлено деталі оновлення 11 січня, щоб адміністратори та користувачі могли ознайомитися з оновленим дизайном і новими можливостями.

Невеликий редизайн

Десь наприкінці 2020 або на початку 2021 року – коли була випущена перероблена приладова панель, ми представили новий, відмінний від колишнього дизайн musdb. Якщо в старому дизайні бічні панелі розташовувалися з відступом від межі вікна, то в приладовій панелі бічна панель йде до самого лівого краю вікна. Якщо в старому дизайні весь вміст сторінки (за винятком бічних панелей і навігації) розташовувався прямо на тлі, то в приладовій панелі для кожного розділу сторінки передбачено чітко визначені рамки.

Поступово сторінки, які зазнали серйозних оновлень (наприклад, сторінка налаштувань усієї установи та сторінка редагування зображень) або були додані нещодавно (управління завданнями; календар), також отримали новий макет сторінки. Таким чином, ми могли поступово впроваджувати новий дизайн і, як ми сподіваємося, змогли підготувати користувачів до того, який вигляд матиме musdb у майбутньому.

Але за збереження двох різних макетів сторінок поруч один з одним доводиться платити складнішим обслуговуванням і (очевидно) менш злагодженим користувацьким досвідом. З цим оновленням “новий” макет сторінки буде поширено на всі сторінки.

Інші новини

У листопаді 2022 року ми представили карти, на яких місцезнаходження музею або ближчого, безіменного об’єкта (наприклад, місце знахідки археологічних предметів) можна було визначити простим клацанням миші на карті. Колеги з Баден-Вюртемберга попросили надати їм можливість вводити геокоординати безпосередньо в поле введення, що взаємодіє з картою, оскільки вони вже знають координати, які їм потрібно було вказати. Карти тепер оснащені кнопкою в правому верхньому кутку, яка дає змогу користувачеві відкрити діалог введення геокоординат місця розташування.

Користувацькі звіти

Дотепер звіти в musdb були виключно попередньо складеними та надавалися в комплекті з програмним забезпеченням. Однак, зрештою, музеї часто мають зобов’язання за місцевим законодавством або вже мають форми чи звіти, які загалом можуть бути використані для тієї чи іншої мети. Тепер користувачі можуть самостійно визначати шаблони для форматів звітів і генерувати звіти на основі результатів пошуку, виставки (та її об’єктів) або позики (та її об’єктів). Це може бути використано, наприклад, для автоматичного створення договорів позики.

Щоб визначити формат звіту, необхідно мати роль користувача “директор музею” та перейти на сторінку налаштувань усієї установи. У нижній частині сторінки можна завантажити шаблон звіту, в якому будуть відмічені місця, де інформація про об’єкт буде заповнена системою.

Для спрощення реалізації та підвищення безпеки на стороні сервера можна завантажувати тільки текстові звіти. HTML може бути найбільш корисним форматом для текстової інформації з форматуванням; CSV – для табличної інформації.

Таймерна генерація звітів та експорту

Однією з функцій, про яку часто запитували, але яку досі було важко реалізувати, є можливість для музеїв генерувати експортні звіти автоматично та без участі користувача. Тепер це можливо як для XML-звітів, так і для нових користувацьких форматів звітів.

Звіти та експорт за розкладом налаштовуються на сторінці налаштувань усієї установи. Для створення кожного таймінгового звіту необхідно вказати:

• дата початку (коли має бути надіслано перший звіт?)
• інтервал (щотижневий, щомісячний, щорічний)
• вибірку; зазвичай це пошуковий запит, написаний мовою запитів для пошуку об’єктів
• електронну адресу одержувача.

Примітка: Оскільки musdb використовується багатьма музеями спільно, нам довелося встановити деякі обмеження на цю функцію. Якщо розмір експортованого файлу перевищує 10 МБ (це також розмір, який багато поштових серверів просто забороняють для вкладень), конфігурацію для автоматичного звіту автоматично видаляють, а одержувачу надсилають відповідне сповіщення.

Введення інформації про літературу

Ймовірно, найбільш затребуваним аспектом musdb є робота із записами літератури. Майже будь-який запит на забезпечення сумісності літературних записів з іншими програмами (наприклад, Zotero для управління бібліографією або бібліотечними каталогами) вимагає наявності поля для визначення типу даного запису про літературу. Те саме стосується і більшості поширених стандартів цитування: У межах одного стилю цитування спосіб цитування для книг відрізняється від способу цитування для статей, для веб-сторінок або для архівних матеріалів.

Тепер ми додали це досить важливе поле і – оскільки це можливо за допомогою нового поля – відображаємо BibTeX-подання запису про літературу в новій бічній панелі доступу до літератури.

Користувацькі налаштування за замовчуванням для додавання нових об’єктів

Музеї мають спеціалізації, як і люди. Це не рідкість, коли люди майже завжди вводять об’єкти, наприклад, певного типу, особливо якщо вони працюють у контексті проєкту, орієнтованого на конкретну колекцію (“Оцифрувати всі картини музею”). Аналогічно, всі користувачі в музеї, найімовірніше, використовують одні й ті самі одиниці виміру об’єктів.

Щоб прискорити введення даних у разі таких полів із незмінним вмістом, користувачі тепер зможуть встановлювати значення за замовчуванням для “прямих” текстових полів об’єкта. Однак встановити значення за замовчуванням для посилань [наприклад, на колекції або простори] і полів, що повторюються, набагато складніше, і це поки не передбачено в цьому оновленні. Значення за замовчуванням для формуляра додавання нових об’єктів можна встановити в персональних налаштуваннях.

Зверніть увагу, що значення за замовчуванням можна встановити тільки для тих полів, які відображаються на сторінці додавання об’єкта. Що стосується найосновніших і загальнообов’язкових полів, то визначити, які поля доступні на сторінці додавання об’єкта, можна в налаштуваннях усієї установи.

Займи

Щоб краще уявити процес надання позики в музеї – від запиту, обговорення зі страховиками до остаточного відправлення предметів – ми додали стислий, але, сподіваємося, досить повний контрольний список етапів надання позики в музеї в бічній панелі сторінки позик. Контрольний список охоплює найпоширеніші етапи впродовж усього процесу позики і дає змогу просто зафіксувати прогрес у роботі з позикою. Якщо поле було змінено, то вказується останній користувач, який вносив зміни в цей пункт контрольного списку. Це дає змогу простежити за ходом роботи надалі.

Ми також дізналися про дуже очевидний, але досі не помічений приклад: Заявки на позику, які були відхилені. Ми додали поле, якого бракує, щоб врахувати цей статус позики.

Нарешті, з’явилася можливість пов’язувати позики з виставками. Усі позики виставки можуть бути перераховані разом на вкладці відповідної сторінки виставки.

На мить повернемося до чек-листа: Одним із найбільш примітних пунктів, який можна вибрати в контрольному списку позик, є “обмін метаданими”. Додавання цього пункту може бути спірним, але передбачає такі кроки. У листопаді 2022 року ми додали можливість імпортувати інформацію про об’єкт позики відповідно до майбутнього стандарту EODEM. Ми сподіваємося, що зможемо реалізувати експорт EODEM до того, як оновлення буде перенесено в робочі версії, щоб принаймні музеї, які використовують musdb, могли працювати з позиками з мінімальним дублюванням даних.

Виставки

Як уже згадувалося вище, позики тепер можуть бути пов’язані з виставками. Нова вкладка на сторінці виставки дає змогу перерахувати всі позики, що відбулися в контексті цієї виставки.

Список об’єктів виставки тепер також перероблено. Під час зв’язування об’єкта з виставкою тепер можна вказати виставковий зал, у якому експонуватиметься об’єкт. Якщо ця інформація була введена для об’єктів виставки, список об’єктів цієї виставки буде згрупований за місцями розташування об’єктів.

Інтеграція з Nextcloud

Продовжуючи тему глибшої інтеграції musdb у повсякденну роботу музеїв, ми додали можливість інтегрувати musdb з музейним сховищем Nextcloud. Якщо інтеграцію з Nextcloud активовано, новий віджет буде доступний у бічній панелі більшості сторінок редагування (наприклад, для кредитів).

Цей віджет відображає посилальний ID об’єкта (наприклад, LOA-000000005 для позики з ID 5). Якщо цей ідентифікатор присутній у папці або імені файлу на Nextcloud (наприклад, є папка для всього, що стосується кредиту, яка матиме назву “2022 Loan Brisbane [LOA-000000005]”), musdb може визначити папку або файл як такі, що належать позиці, і перерахувати їх у віджеті. Якщо ID присутній в імені папки, вміст папки буде відображено в musdb.

Щоб ця інтеграція працювала, musdb під’єднується до Nextcloud за допомогою WebDAV (на жаль, нам довелося використати деякі властивості, ексклюзивні для WebDAV-інтерфейсів Nextcloud і, ймовірно, OwnCloud, що робить нашу інтеграцію несумісною з іншими рішеннями для зберігання даних, які також використовують WebDAV, наприклад, Google Drive). А для підключення через WebDAV необхідна інформація для отримання авторизованого доступу.

Щоб налаштувати інтеграцію з Nextcloud, необхідно спочатку встановити базову URL-адресу екземпляра Nextcloud установи на сторінці налаштувань усієї установи. Це потрібно зробити лише один раз для кожної установи і просто надати musdb інформацію, необхідну для визначення місця розташування екземпляра Nextcloud.
Після введення базового URL для екземпляра Nextcloud на сторінці особистих налаштувань musdb можна ввести ім’я користувача та пароль для Nextcloud (в ідеалі – токен додатка [може бути створений у Налаштування > Безпека в Nextcloud]). Після введення цих даних інтеграцію Nextcloud буде активовано.

Сторінки установ і контактів

Сторінки установ і контактів практично не змінилися. Однак у бічні панелі цих сторінок було додано простий, але, можливо, корисний невеликий віджет: Блок адреси для швидкого копіювання/вставки адреси, наприклад, у шапку листа.

Об’єкти

І нарешті: Об’єкти. В об’єктах було додано багато нових полів, в основному для адміністративних завдань.

На вкладці “адміністрування” на сторінках об’єктів тепер можна “забронювати” об’єкт. Якщо об’єкт заброньовано наразі або буде заброньовано протягом наступного тижня, у бічній панелі з’явиться відповідний індикатор.

Для реєстрації історії об’єкта в музеї ми додали кілька журналів:

• Пошкодження предмета (вкладка “Реставрація”)
• Консервація та реставрація об’єкта (вкладка “Реставрація”)
• Планові перевірки (вкладка “Адміністрування”). Ці перевірки охоплюють, наприклад, перевірку стану, а також аудит повноти інформації про об’єкт у musdb. У цьому розділі є повідомлення, яке може бути надіслано в разі майбутньої перевірки.

Аналогічним чином у musdb тепер можуть бути відображені деакцесії/вибуття об’єктів.

Знову прагнучи до найбільш практичних додатків, ми нарешті реалізували прив’язку фактичного / постійного місця розташування об’єкта до “простору”, а не просто ідентифікували його за допомогою текстового поля. Таким чином, тепер можна шукати об’єкти, які наразі не перебувають у місці їхнього передбачуваного постійного розташування.

Ми також додали кілька простих текстових полів, які часто присутні в імпорті та запропоновані в контрольному списку вимог до програмного забезпечення від Canadian Heritage Information Network. А саме: гендер об’єкта (для біологічних видів), колір об’єкта і форма об’єкта.

Post image: Courtesy NASA/JPL-Caltech.