Development of access management methods to information from WIKI resources

Development of access management methods to information from WIKI resources

The prospects and scope of Wiki technologies are considered, the structure of the content re presentation and MediaWiki software are analyzed. Considerable attention is given to architecture of MediaWiki and the components of this architecture. The problem deal with the need to access management to...

Повний опис

Збережено в:
Бібліографічні деталі
Дата:2020
Автори: Rogushina, J.V., Grishanova, I.J.
Формат: Стаття
Мова:Ukrainian
Опубліковано: PROBLEMS IN PROGRAMMING 2020
Теми:
MediaWiki
Wiki resource
access management
Great Ukrainian Encyclopedia
UDC 004.853
004.55
Онлайн доступ:https://pp.isofts.kiev.ua/index.php/ojs1/article/view/389
Теги: Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:Problems in programming
Завантажити файл: Pdf

Репозитарії

Problems in programming
id pp_isofts_kiev_ua-article-389
record_format ojs
resource_txt_mv ppisoftskievua/b1/0b510b997373cab184f55910123deab1.pdf
spelling pp_isofts_kiev_ua-article-3892020-12-02T14:52:38Z Development of access management methods to information from WIKI resources Разработка методов управления доступом к информации в Wiki-ресурсах Розробка методів керування доступом до інформації у WIKI-ресурсах Rogushina, J.V. Grishanova, I.J. MediaWiki; Wiki resource; access management; Great Ukrainian Encyclopedia UDC 004.853, 004.55 MediaWiki; Wiki-ресурс; управление доступом; Большая украинская энциклопедия УДК 004.853, 004.55 MediaWiki; Wiki-ресурс; керування доступом; Велика українська енциклопедія УДК 004.853, 004.55 The prospects and scope of Wiki technologies are considered, the structure of the content re presentation and MediaWiki software are analyzed. Considerable attention is given to architecture of MediaWiki and the components of this architecture. The problem deal with the need to access management to the content of Wiki-resources in accordance with the specifics of the information contained in such resources is identified. The results of the analysis show that the basic tools of MediaWiki are not capable to allow a satisfactory solution to this problem. Therefore, we need to create specialized software that is based on the content classification with the  use of separate namespaces, categories, templates and semantic properties extracted from MediaWiki. Such software has to be independent of the MediaWiki core and be based on programming of content analysis at the skin level. We test the proposed solution in the process of  development of the portal version of the Great Ukrainian Encyclopedia (e-vue) with use of  knowledge regarding the knowledge base structure of this portal.Prombles in programming 2020; 1: 33-46 Рассмотрены перспективы и область применения Wiki-технологий, проанализирована структура представления контента и программное обеспечение MediaWiki. Значительное внимание отводится архитектуре MediaWiki и компонентам этой архитектуры. Определена проблема, связанная с необходимостью управления доступом к контенту Wiki-ресурсов в соответствии со спецификой информации, которая содержится в таких ресурсах. Результаты анализа показали,  что базовые средства MediaWiki не позволяют получить удовлетворительное решение этой задачи.  Поэтому возникает потребность в создании специализированного программного обеспечения, которое базируется на классификации контента с использованием  отдельных пространств имен, категорий, шаблонов и семантических свойств. которые извлекаются из MediaWiki,  и являются независимыми от ядра MediaWiki, а базируется на программировании анализа контента на уровне скина. Приведенное решение апробировано в разработке портальной версии Большой украинской энциклопедии (е-вуе) и использует знания относительно структуры базы знаний этого портала.Prombles in programming 2020; 1: 33-46 В роботі аналізуються технологічні засади розробки Wiki-ресурсів на основі програмного забезпечення  MediaWiki, розглядаються проблеми доступу до інформації у цих ресурсах та наводяться методи та засоби вирішення цих проблем. Значна увага приділяється архітектурі MediaWiki та складовим цієї архітектури. Розроблені в результаті аналізу  рішення апробовано у розробці порталу Великої української енциклопедії (е-ВУЕ) .Prombles in programming 2020; 1: 33-46 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2020-02-28 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/389 10.15407/pp2020.01.033 PROBLEMS IN PROGRAMMING; No 1 (2020); 33-46 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 1 (2020); 33-46 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 1 (2020); 33-46 1727-4907 10.15407/pp2020.01 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/389/394 Copyright (c) 2020 PROBLEMS IN PROGRAMMING
institution Problems in programming
baseUrl_str https://pp.isofts.kiev.ua/index.php/ojs1/oai
datestamp_date 2020-12-02T14:52:38Z
collection OJS
language Ukrainian
topic MediaWiki
Wiki resource
access management
Great Ukrainian Encyclopedia
UDC 004.853
004.55
spellingShingle MediaWiki
Wiki resource
access management
Great Ukrainian Encyclopedia
UDC 004.853
004.55
Rogushina, J.V.
Grishanova, I.J.
Development of access management methods to information from WIKI resources
topic_facet MediaWiki
Wiki resource
access management
Great Ukrainian Encyclopedia
UDC 004.853
004.55
MediaWiki
Wiki-ресурс
управление доступом
Большая украинская энциклопедия
УДК 004.853
004.55
MediaWiki
Wiki-ресурс
керування доступом
Велика українська енциклопедія
УДК 004.853
004.55
format Article
author Rogushina, J.V.
Grishanova, I.J.
author_facet Rogushina, J.V.
Grishanova, I.J.
author_sort Rogushina, J.V.
title Development of access management methods to information from WIKI resources
title_short Development of access management methods to information from WIKI resources
title_full Development of access management methods to information from WIKI resources
title_fullStr Development of access management methods to information from WIKI resources
title_full_unstemmed Development of access management methods to information from WIKI resources
title_sort development of access management methods to information from wiki resources
title_alt Разработка методов управления доступом к информации в Wiki-ресурсах
Розробка методів керування доступом до інформації у WIKI-ресурсах
description The prospects and scope of Wiki technologies are considered, the structure of the content re presentation and MediaWiki software are analyzed. Considerable attention is given to architecture of MediaWiki and the components of this architecture. The problem deal with the need to access management to the content of Wiki-resources in accordance with the specifics of the information contained in such resources is identified. The results of the analysis show that the basic tools of MediaWiki are not capable to allow a satisfactory solution to this problem. Therefore, we need to create specialized software that is based on the content classification with the  use of separate namespaces, categories, templates and semantic properties extracted from MediaWiki. Such software has to be independent of the MediaWiki core and be based on programming of content analysis at the skin level. We test the proposed solution in the process of  development of the portal version of the Great Ukrainian Encyclopedia (e-vue) with use of  knowledge regarding the knowledge base structure of this portal.Prombles in programming 2020; 1: 33-46
publisher PROBLEMS IN PROGRAMMING
publishDate 2020
url https://pp.isofts.kiev.ua/index.php/ojs1/article/view/389
work_keys_str_mv AT rogushinajv developmentofaccessmanagementmethodstoinformationfromwikiresources
AT grishanovaij developmentofaccessmanagementmethodstoinformationfromwikiresources
AT rogushinajv razrabotkametodovupravleniâdostupomkinformaciivwikiresursah
AT grishanovaij razrabotkametodovupravleniâdostupomkinformaciivwikiresursah
AT rogushinajv rozrobkametodívkeruvannâdostupomdoínformacííuwikiresursah
AT grishanovaij rozrobkametodívkeruvannâdostupomdoínformacííuwikiresursah
first_indexed 2025-07-17T09:50:36Z
last_indexed 2025-07-17T09:50:36Z
_version_ 1850410004157300736
fulltext Моделі та засоби систем баз даних і знань © І.Ю. Гришанова, Ю.В. Рогушина, 2020 ISSN 1727-4907. Проблеми програмування. 2020. № 1 33 УДК 681.3 https://doi.org/10.15407/pp2020.01.033 І.Ю. Гришанова, Ю.В. Рогушина РОЗРОБКА МЕТОДІВ КЕРУВАННЯ ДОСТУПОМ ДО ІНФОРМАЦІЇ WIKI-РЕСУРСАХ В роботі аналізуються технологічні засади розробки Wiki-ресурсів на основі програмного забезпе- чення MediaWiki, розглядаються проблеми доступу до інформації у цих ресурсах та наводяться ме- тоди та засоби вирішення цих проблем. Значна увага приділяється архітектурі MediaWiki та складо- вим цієї архітектури. Розроблені в результаті аналізу рішення апробовано у розробці порталу Вели- кої української енциклопедії (е-ВУЕ) . Ключові слова: MediaWiki, Wiki-ресурс, керування доступом, Велика українська енциклопедія. Вступ Wiki-технології є основою для створення структурованих інформаційних ресурсів великого обсягу, орієнтованих на одночасне використання через Web вели- кою кількістю користувачів. Таке подання інформації є зручним та інтуїтивно зрозу- мілим для широких кіл користувачів, має достатню виразну здатність для відобра- ження досить складних змістових відно- шень між окремими елементами ресурсу. Нині Wiki-технології широко засто- совуються для створення різноманітних відкритих енциклопедійних ресурсів. На- приклад, портальна версія Великої україн- ської енциклопедії (е-ВУЕ) базується на програмному забезпеченні MediaWiki [1], дозволяє подавати авторський та рецензо- ваний мультимедійний контент із склад- ною системою зв’язків та навігації [2]. Процес створення контенту є централізо- ваним та контролюється модераторами на- укових напрямків, що виключає безпосе- редню участь користувачів у редагуванні даних. Частина даних у е-ВУЕ призначена для забезпечення семантичного пошуку та навігації і не орієнтована на безпосереднє використання кінцевими користувачами, що призводить до необхідності керувати доступом до інформації відповідно до ро- лей користувачів цього порталу. Але тех- нологія MediaWiki не підтримує безпосе- редньо такий функціонал, і тому виникає потреба у розробці таких спеціалізованих програмних засобів, що дозволяють вирі- шувати ці задачі. Wiki-технологія створення відкритих інформаційних ресурсів Wiki-ресурси являють собою перс- пективний шлях розвитку приватних і публічних баз знань. Оригінальна систе- ма Wiki була винайдена в 1995 р. У. Канін- гемом [3] для Web-вузла Pattern Languages Community, щоб спростити спільне ство- рення й документування програмного за- безпечення. Всесвітньо відомий приклад застосування технології Wiki – це Вікіпе- дія, найбільша з безкоштовних онлайн- енциклопедій [4]. Під Wiki-технологією зазвичай ро- зуміють таку технологію побудови Wiki- ресурсу, яка дає змогу відвідувачам брати участь у редагуванні його вмісту – виправ- ляти помилки, додавати нові матеріали, не використовуючи спеціальні програми, не реєструючись на сайті й не вивчаючи мову HTML [5]. Кожна окрема сторінка Wiki- ресурсу називається Wiki-сторінка (Wiki page). Створення й редагування Wiki- сторінок не потребує від користувачів знання мови HTML: механізм Wiki надає можливість написання документів за до- помогою простої мови розмітки й Web- браузеру. Всі Wiki-сторінки мають уніка- льні назви, на які можна посилатися з ін- ших статей, і вміст. Інформація, представ- лена у Wiki, має нелінійну навігаційну структуру: кожна сторінка, зазвичай, міс- тить велику кількість гіперпосилань на ін- ші сторінки. https://doi.org/10.15407/pp2020.01.033 Моделі та засоби систем баз даних і знань 34 У 2006 році термін Wiki додано до онлайнового Оксфордського Словника Англійської мови (OxfordEnglish Dictiona- ry, OED) як позначення моделі сайтів, кон- тент яких може змінювати сам користувач. Формат Wiki-сторінок (Wiki-текст) – це спрощена мова розмітки, що викорис- товується для того, щоб виділити в тексті різні структурні й візуальні елементи або вказати на них. Кожна Wiki-система має власний стиль і синтаксис залежно від реа- лізації. У багатьох реалізаціях Wiki гіпер- посилання показується таким, яким воно є насправді, на відміну від HTML, де неви- диме гіперпосилання може мати довільний видимий текст або зображення. Для створення та підтримки Wiki- ресурсу необхідно спеціальне програмне забезпечення (ПЗ) – Wiki-рушій, який за- безпечує роботу відповідного Web-сайту. Рушій Wiki-сайту робить запис змін так, щоб у будь-який час сторінку можна було б повернути до кожного з її попередніх станів. Wiki-система може також містити різні інструментальні засоби для простого контролювання стану Wiki, що постійно змінюється, а також для обговорювання й розв’язання проблем, що виникають через різні погляди на зміст Wiki-сторінок. Популярність технологій Wiki сприяла появі великої кількості реалізацій практично для всіх можливих платформ і конфігурацій ПЗ. Крім того, різні реаліза- ції Wiki неоднаково розширюють основні можливості технології, додаючи, напри- клад, убудовані графічні редактори чи сер- віси WAP. Але загальна орієнтованість на створення відкритих інформаційних ресу- рсів (ІР) призводить до певних проблем, що пов’язані з обробкою персональних да- них та із захистом інформації від несанк- ціонованого доступу (приміром, до служ- бової інформації, що не призначається для кінцевого користувача, але необхідна для ефективної організації Wiki-ресурсу). MediaWiki як технологічна основа побудови Wiki-ресурсів Широко вживаним рішенням для створення Wiki-ресурсів є MediaWiki [6]. Це програмне забезпечення розроблено для створення найбільш відомого Wiki- ресурсу – Вікіпедії. Воно враховує розпо- ділену розробку незалежними розробни- ками додаткових плагінів та функціоналу без зміни архітектури. MediaWiki розроблено для підтрим- ки спільноти, яка створює та керує вільне повторно використовуване знання на від- критій платформі. Тому MediaWiki не включає стандартний функціонал корпора- тивних систем керування контентом (CMS), натомість пропонує різноманітні інструменти для боротьби зі спамом та вандалізмом. Архітектура MediaWiki повинна враховувати не тільки розподілене вико- ристання ПЗ, постійно зростаючу кіль- кість користувачів та авторів контенту, патрулювання для збереження цілісності контенту, боротьби зі спамом та вандалі- змом, а також і розподілений процес роз- робки ПЗ як афілійованими розробника- ми, так і окремими сторонніми користу- вачами, надавши їм можливість додавати власні додатки до загальної бази програ- много коду. Для організації спільного відкрито- го процесу розробки з використанням зу- силь різних розробників та волонтерів, бу- ло обрано такі найбільш поширені та оп- тимальні інструменти: LAMP платформа – мова PHP (з подальшим використанням фреймворків Symphony та інших, як Zend Framework), база даних MySQL/MariaDB (використовується як базова з можливістю зміни на PostgreSQL, SQLite тощо), jQuery як клієнтська бібліотека JavaScript. Розро- бка відбувається в стилі відкритого коду [7] і координується спеціальними спільно- тами та групами WikiMedia Foundation. Документація коду генерується автомати- чно, загальна інформація публікується на сторінках Вікіпедії. В ретроспективі визнано, що багато рішень прийняті не зовсім оптимально, а деякі були помилковими. Але зважаючи на невелику кількість розробників і волонтер- ський характер участі у проекті, швидкість розробки і невеликий обсяг коду, важко критикувати засновників проекту. Проект зростає, розвивається і постійно викорис- Моделі та засоби систем баз даних і знань 35 товується, тому базові рішення (навіть ті, які нині визнано не оптимальними) здебі- льшого кардинально не змінюються, а ве- деться пошук рішень, які зберігають існу- ючу архітектуру. На даний час нам не вдалося знайти більш-менш сталого і змістовного визна- чення архітектури MediaWiki. Ресурси, пов’язані із розширенням функціоналу MediaWiki, містять базові рекомендації для розробників, опис змінних, опис таб- лиць БД, але не надають формалізований опис архітектури. Для забезпечення безпе- ки, розробники ядра і ревізіонери коду роз- робили жорсткі правила кодування, а та- кож надали набори обгорток (wrappers) для екранування вхідних html-даних та ескей- пування sql-запитів (класи WebRequest, Sanitizer). MediaWiki може мати багато мож- ливих варіацій конфігурацій, параметри яких зберігаються в глобальних php- змінних. Значення за замовчуванням вста- новлені в DefaultSettings.php, але адмініст- ратор може змінити їх, вказавши нові або додаткові значення в файлі LocalSet- tings.php. З точки зору безпеки та можли- вості виникнення конфліктів, це не є доб- рим рішенням, але процес розвитку ПЗ MediaWiki має довгу і ще не закінчену іс- торію руху від глобальних змінних до об`єктів. Для збереження наступності вер- сій і підтримки старих, конфігурація збері- гається за допомогою змінних. MediaWiki використовує реляційну БД (за замовчуванням це MySQL), і Вікі- педія використовує саме цю БД, але спіль- нота розробила підтримку інших БД, таких як PostgreSQL, Oracle, SQLite. Під час пер- винної процедури встановлення адмініст- ратор обирає необхідну БД. ПЗ MediaWiki забезпечує рівень абстракції БД і рівень абстракції запитів до БД, що полегшує ро- зробникам доступ до неї. В процесі розвитку MediaWiki схе- ма БД багаторазово змінювалася, найбільш значною зміною було розділення місця зберігання текстів і відслідкування ревізій в MediaWiki 1.5. На даний час БД склада- ється з десятків таблиць, які містять дані про контент (наприклад page, revision, category, recentchanges), про користувачів (user, user_groups), про медіа файли (image, filearchive), кешування (objectcache, l10n_cache, querycache), внутрішні засоби (job – для виконання черги задач), а також може містити інші додаткові дані, що встановлені додатково та є необхідними для певних плагінів. Абстрактна модель архітектури MediaWiki Архітектура MediaWiki на абстрак- тному рівні містить (рис. 1): - базу даних; - базове ядро MediaWiki; - набір плагінів, які розширюють функціональні можливості ПЗ; - набір скінів (шаблонів відобра- ження контенту сторінок та засобів навіга- ції). Wiki-ресурс Рис. 1. Абстрактна модель архітектури MediaWiki Архітектурно відображення контен- ту Web-сторінок (навігації та контенту сторінок) максимально відокремлено від- повідно до MVC моделі (model-view- control) і винесено на рівень скінів (шаб- лонів відображення), хоча деякі невеликі частини інтерфейсу, які історично створені раніше, не вдалось повністю відокремити від основного коду бізнес-логіки. Моделі та засоби систем баз даних і знань 36 Набір стилів оформлення (так звані skin) дозволяють користувачам модифіку- вати зовнішнє оформлення MediaWiki [8]. Зазвичай базовий комплект програмного забезпечення містить 4 базових набора: Vector, Monobook, Cologne Blue та Modern. Стиль, встановлюваний за замов- чуванням – Vector. Деякі набори стилів не підтримують мобільної версії. Додат- кові компоненти, такі як JavaScript, також функціонують тільки в певних наборах стилів. На даний час в е-ВУЕ прийнятий для використання як базовий додатковий набір стилів оформлення Foreground, який фокусується на виділенні контенту, підт- римує адаптивні макети та має спеціальні заздалегідь визначені класи для підтрим- ки функціоналу Semantic MediaWiki. Цей набір побудовано на Zurb's Foundation Framework (v4.3.2), який орієнтований у першу чергу на підтримку мобільних при- строїв та розширеного адаптивного фронт-енд фреймворку. Скін (skin) – це набір елементів, що визначають дизайн інтерфейсу (стилі, меню, шрифти тощо). У MediaWiki скіни – це PHP-класи, кожен з яких розширює батьківський клас Skin; вони містять фун- кції, які збирають інформацію, необхідну для генерування HTML. На відміну від плагінів, розробка або налаштування скі- нів – тяжка і нестандартна задача. Напри- клад, стандартний скін "MonoBook" дов- гий час було важко налаштувати під нову версію, оскільки він містив багато стилів CSS, які підтримують старі браузери; ре- дагування шаблону або CSS вимагало ба- гатьох наступних змін, щоб відобразити зміни для всіх браузерів і платформ. Скін задає стиль оформлення сторі- нок (з використанням CSS та JavaScript): - розташування елементів навіга- ції, інформаційних блоків, кнопок тощо; - фон сторінок та фон елементів сторінки; - типи та розміри шрифтів для рі- зних типів абзаців; - розміри відступів від блоків та елементів сторінки. Набір стилів оформлення розроб- люється і задається один раз і поширюєть- ся на всі сторінки. Зазвичай Web-сторінка може мати стандартний набір зон: навігаційний блок зверху, зони меню навігації ліворуч та праворуч, основний зміст сторінки в сере- дині, і внизу сторінки – зона підвалу. На- бір стилів оформлення Foreground повніс- тю змінює макет зовнішнього відображен- ня Wiki-сторінки та дозволяє додавати нові елементи інтерфейсу. В е-ВУЕ всі функці- ональні меню перенесені в горизонтальний навігаційний рядок у вигляді випадаючих меню, що знаходиться наверху сторінки. Стандартна сторінка MediaWiki за замовчуванням містить певний обмежений набір компонентів (рис. 2): - елементи персональних інстру- ментів та налаштування для зареєстрова- ного користувача; - меню набору дій, які можливо робити з сторінкою (редагувати, обгово- рення, перегляд історії тощо); - форма пошуку по сайту; - системні повідомлення (site notice); - гасло сторінки; - рядок сторінки, вищої за таксо- номічним поділом та джерело перепоси- лання (redirected from); - блок контенту сторінки, який може містити текст, мультимедійну інфо- рмацію, формули, таблиці, підзаголовки, блок змісту. Контент сторінки може розді- лятися на частини, кожна частина може редагуватися окремо, для чого з`являється елемент «Редагувати» над кожною виділе- ною частиною; - блок категорій, до яких нале- жить сторінка; - нижній колонтитул з піктогра- мами та посиланнями; - ліва бічна панель (sidebar), яка містить посилання на певні головні сторін- ки, сторінки довідок, блок посилань на ін- струменти та блок посилань на версії сто- рінки іншими мовами; - індикатор статусу сторінки. Моделі та засоби систем баз даних і знань 37 Інструменти Пошук Дії Контент Гасло Рис. 2. Основні елементи Wiki-сторінки Процес виконання Web-запиту в MediaWiki Головною точкою доступу в MediaWiki є index.php, який керує більшіс- тю запитів, поданих до серверу. Код цього модулю виконує перевірку безпеки, заван- тажує встановлені конфігураційні значен- ня з includes/DefaultSettings.php, виконує конфігурацію за допомогою includes/ Setup.php, після чого встановлює конфігу- раційні змінні, що відповідають конкрет- ному серверу і прописані в файлі LocalSettings.php. Потім він створює об'єкт MediaWiki ($mediawiki) та створює об'єкт Title ($wgTitle) в залежності від заголовка та параметрів дії, вказаних в URL-запиті. index.php може приймати різні па- раметри дії, вказані в URL-запиті; дією за замовчуванням є перегляд (view), яка пока- зує звичайний вигляд вмісту статті. На- приклад, запит https://en.wikipedia.org/w/ index.php?title=Apple&action=view відо- бражає зміст статті "Apple" в англійській Вікіпедії. Також часто застосовують на- ступні дії: edit (відкриття статті для реда- гування), submit (для попереднього перег- ляду редагування або збереження статті), history (для відображення історії змін стат- ті) та watch (для додавання статті до спис- ку спостереження користувача). Адмініст- ративні дії включають delete (для видален- ня статті) та protect (захист для запобіган- ня редагуванню статті). Для обробки більшості URL-запитів викликається метод MediaWiki::performRequest(). Він перевіряє наявність поганих заголовків, обмеження читання, локальні переспрямування та ци- кли переспрямування та визначає для яко- го типу сторінки запит – для звичайної чи спеціальної. Запити звичайної сторінки переда- ються методу MediaWiki::InitializeArticle(), який створює для сторінки об’єкт Article ($wgArticle), а потім методу MediaWiki::performAction(), який обробляє "стандартні" дії. Після завершення дії ви- конується MediaWiki::finalCleanup(), який Моделі та засоби систем баз даних і знань 38 доопрацьовує запит, здійснюючи закін- чення транзакцій БД, виводячи згенерова- ний HTML і запускаючи відкладені онов- лення, які поставлені в чергу завдань. MediaWiki::restInPeace() закінчує виконан- ня відкладених оновлень та закриває зав- дання. Якщо запитувана сторінка є спеціа- льною (тобто не звичайна сторінка Wiki- ресурсу, а спеціалізована сторінка, пов’язана з відповідним програмним за- безпеченням або виконанням певних спе- ціальних операцій, наприклад, Статисти- ка), замість InitializeArticle() викликається SpecialPageFactory::ExecutePath і викону- ється відповідний PHP скрипт. Спеціальні сторінки можуть робити всілякі операції і кожна має певну мету, як правило, незале- жну від будь-якої статті чи її змісту. Спе- ціальні сторінки включають різного роду звіти (останні зміни, журнали, категорії без категорій) та засоби адміністрування Wiki (блоки користувачів, зміни прав користу- вача). Послідовність їх виконання зале- жить від їх функції. Багато функцій містять код профі- лювання, який дає можливість, якщо про- філювання включено, слідкувати за робо- чим процесом виконання, що корисно для відлагодження. Профілювання здійсню- ється за допомогою виклику функцій wfProfileIn та wfProfileOut, які відповідно запускають та зупиняють профілювання; обидві функції приймають ім'я функції як параметр. На сайтах WikiMedia (таких як Вікіпедія, Вікідата тощо), щоб зберегти продуктивність, профілювання зазвичай відключене або проводиться на один від- соток від усіх запитів. Під час перегляду сторінки HTML- код може бути взято з кешу. Якщо ж кешу- вання відключене або сторінка кожен раз генерується заново, то спочатку розгорта- ються шаблони, функції парсеру та змінні. В результаті генерується розширений Wiki- текст, що є проміжним результатом, який можна побачити за допомогою Special: ExpandTemplates, і який залежить від: - Wiki-тексту; - шаблонів, на які прямо чи опо- середковано є посилання; - функцій і параметрів парсеру, на які прямо чи опосередковано є поси- лання; - значень змінних, на які прямо чи опосередковано є посилання. Далі цей розширений Wiki-текст перетворюється в HTML-код; він надсила- ється користувачеві та містить посилання на CSS, JavaScript та файли зображень. Користувач може побачити цей проміжний результат, застосувавши в браузері опцію «view source». HTML-код для певної сто- рінки залежить від: - розширеного Wiki-тексту; - режиму, перегляд чи редагу- вання (див. далі); - наявності внутрішньо пов’яза- них сторінок (дає посилання для перегляду чи редагування); - скіну та інших налаштувань ко- ристувача; - імені користувача; - статусу користувача (більше посилань, якщо адміністратор тощо); - простору імен (визначає поси- лання на сторінку Talk або у випадку Talk- сторінки – відповідну сторінку); - чи відслідковує користувач сторінку (надає посилання для включення чи відключення відслідковування за змі- нами); - чи була нещодавно відредаго- вана Talk-сторінка користувача (видає по- відомлення). Нарешті, браузер рендерить HTML з використанням файлів, на які є посилан- ня. Результат, який користувач бачить на екрані, залежить від: - HTML-коду; - файлів, на які посилається код HTML, таких як вставлені зображення, CSS-файли на стороні сервера та файли JavaScript; - браузера та його налаштувань, включаючи, можливо, локальний файл CSS та роздільну здатність екрана. Якщо JavaScript реагує на подію, таку як клацання миші, сторінка на екрані також залежить від цих подій. Це може виникати, наприклад, у разі виконання со- ртування таблиці. Моделі та засоби систем баз даних і знань 39 Якщо користувач обирає вкладку “Редагувати”, клієнту надсилається тільки Wiki-текст (контент сторінки або окремого розділу цієї сторінки з Wiki-розміткою, але без навігаційних елементів). Якщо корис- тувач натискає «Попередній перегляд», на сервер для обробки надсилається нова версія Wiki-тексту, і після обробки сервер надсилає нову вер- сію HTML-коду. Якщо користувач натис- кає кнопку "Зберегти", надсилаючи нову версію статті на сервер, система записує здійснені редагування та надсилає браузе- ру HTML-код нової версії (знову). У де- яких випадках на цьому етапі також відбувається автоматичне перетворення Wiki-тексту. Кешування в MediaWiki Оскільки MediaWiki є базовим ПЗ усіх сайтів WikiMedia, він максимально оптимізований для реалізації високої про- дуктивності. На сайтах WikiMedia більшість за- питів обробляються зворотним кешуван- ням проксі-серверів (Squids) і ніколи не роблять це на серверах застосунків MediaWiki. Проксі-сервери містять ста- тичні версії цілих відтворених сторінок, які служать для простого читання для незареєстрованих користувачів. MediaWiki спочатку підтримує Squid і Varnish та ін- тегрується з цим шаром кешування, на- приклад, сповіщаючи їх про очищення сторінки з кеша, коли вона була змінена. Для зареєстрованих користувачів та вико- нання інших запитів, які не можуть обслу- говувати проксі, Squid пересилає запити на Web-сервер (Apache). Другий рівень кешування викорис- товується, коли MediaWiki надає та збирає сторінку з декількох об'єктів, багато з яких можна кешувати, щоб мінімізувати майбу- тні звернення. Такі об'єкти включають ін- терфейс сторінки (бічна панель, меню, текст інтерфейсу користувача) та власне вміст, проаналізований з Wiki-тексту. Кеш об'єктів у пам'яті доступний в MediaWiki з ранньої версії 1.1 (2003), і це особливо ва- жливо, тому що дозволяє уникнути повто- рного розбору сторінок із складною стру- ктурою та великим обсягом. Дані сесій також можуть зберігати- ся у memcached. Починаючи з версії 1.16, MediaWiki використовує виділений кеш- об'єкт для локалізованого тексту інтерфей- су; це було додано після того, як помітили, що значна частина об'єктів, кешованих у пам'яті, складалася з повідомлень інтер- фейсу, поданих мовою користувача. Останній шар кешування склада- ється з кешування коду PHP (PHP opcode cache), яке зазвичай використовується для прискорення роботи PHP програм. Компі- ляція може бути тривалим процесом; щоб уникнути компіляції PHP-скриптів у код виконання кожного разу, коли вони викли- каються, для зберігання зібраного коду і виконання його безпосередньо без компі- ляції може використовуватися PHP- акселератор. MediaWiki може працювати з багатьма акселераторами, такими як APC, PHP-акселератор та eAccelerator. Також шар кешування абстрактних об'єктів MediaWiki дозволяє зберігати ке- шовані об’єкти в декількох місцях, вклю- чаючи файлову систему, базу даних або opcode cache. Структура контенту MediaWiki Простори імен (namespaces), так са- мо як і спеціальні Wiki-сторінки, були вперше використані в PHP-скрипті для Нупедії (попередниці Вікіпедії) розробни- ком MediaWiki Г.М. Манське [9]. Впро- довж багатьох років namespaces застосову- валися у Wiki-ресурсах, виконуючи лише одну функцію – розділяти різні види кон- тента. За написом namespaces є префіксом, який відокремлений від назви сторінки двокрапкою (наприклад, Talk:, File: та Template:); в основному просторі імен вмі- сту префікса немає. Простори імен вияви- лись важливою особливістю MediaWiki, оскільки вони створюють необхідні перед- умови для спільноти Wiki та встановлю- ють дискусії на метарівні, процеси спіль- ноти, портали, профілі користувачів тощо. Простори імен дозволяють структу- рувати контент Wiki-ресурсів, розділити контент за функціональним призначенням. В межах одного простору імен сторінки можуть бути впорядковані за темами за допомогою категорій. Існує певний список Моделі та засоби систем баз даних і знань 40 вже зарезервованих просторів імен: User – для розділення користувачів, Mediawiki – для службових сторінок ядра MediaWiki, File – для зберігання інформації про фай- ли, Special – для службових сторінок, Template – для сторінок шаблонів. Як було зазначено вище, в загаль- ному вигляді Web-серверна архітектура розподіляє процес отримання результату на етапи: серверну обробку запиту, підго- товку відповіді, відправку та обробку отри- маних даних на клієнті і відображення їх в браузері (або іншому клієнтському ПЗ). Відповідно до цього підходу, про- цес обробки сервером запиту користувача складається з наступних етапів: - виконання запиту користувача і підготовка необхідних для відсилання даних; - перетворення даних у кінцевий формат шляхом трансформації та обгор- тання в html-формат, додавання елементів навігації, інтерфейсу та дизайну; - відправлення згенерованої Web-сторінки клієнту (браузеру). Архітектура MediaWiki пропонує різні способи налаштування та розширен- ня програмного забезпечення. Це можна зробити на різних рівнях доступу: - системні адміністратори мо- жуть встановлювати розширення, скіни, налаштовувати окремі допоміжні програ- ми wiki (наприклад, для відображення мі- ніатюр для зображень та генерування TeX) та глобальні налаштування; - користувачі Wiki з правами sysops (іноді їх також називають "адмініс- траторами") можуть редагувати гаджети, налаштування JavaScript та CSS; - будь-який зареєстрований ко- ристувач може налаштувати власний інте- рфейс, використовуючи свої уподобання (для існуючих налаштувань, скінів та га- джетів) або внести зміни до власної моделі інтерфейсу (використовуючи свої особисті сторінки JS та CSS). Зовнішні програми також можуть спілкуватися з MediaWiki через його API, якщо він включений, в основному роблячи будь-яку функцію та дані доступними для користувача. MediaWiki забезпечує систему гач- ків (hooks) – перехвату, що дозволяють стороннім розробникам запускати корис- тувацький PHP-код до, після або замість коду MediaWiki для конкретних подій. Ро- зширення MediaWiki використовують такі гачки для підключення свого коду. До появи в MediaWiki цих засобів перехвату процес додавання спеціального коду PHP викликав зміну основного коду. За допомогою гачків можливо розширити мову Wiki-розмітки додатковими можли- востями, вводячи нові теги. Екосистема MediaWiki дозволяє розробникам створювати плагіни, які на- зиваються розширеннями (extensions) і ви- користовують гачки. Система розширень має низку недоліків: реєстрація розширень базується на виконанні додаткового коду при кожному запуску системи, а не на ке- шованих даних, що обмежує абстрагуван- ня та оптимізацію та шкодить продуктив- ності MediaWiki. Але в цілому сучасна ар- хітектура розширень є досить гнучкою ін- фраструктурою, яка допомагає зробити спеціалізований код більш модульним, утримуючи основне програмне забезпе- чення від занадто великого збільшення та дозволяючи стороннім користувачам бу- дувати власну функціональність на основі стандартної версії MediaWiki. Використання авторизації для визначення прав доступу до інформації В MediaWiki реалізовано можли- вість розподілу функціоналу за допомогою авторизації. В момент встановлення Wiki- системи є можливість одразу визначити, закритий чи відкритий тип матиме ця сис- тема. Якщо система встановлюється як ві- дкрита, то кожен незареєстрований корис- тувач має повний доступ до контенту всіх сторінок. Авторизація – керування рівнями та засобами доступу до певного захищеного ресурсу, як у фізичному розумінні (доступ до кімнати готелю за карткою), так і в га- лузі цифрових технологій (наприклад, ав- томатизована система контролю доступу) та ресурсів системи залежно від ідентифі- катора і пароля користувача або надання Моделі та засоби систем баз даних і знань 41 певних повноважень (особі, програмі) на виконання деяких дій у системі обробки даних [10]. З позицій інформаційної безпеки авторизація – частина процедури надання доступу для роботи в інформаційній сис- темі, після ідентифікації і автентифікації. Авторизація контролює доступ ле- гальних користувачів до ресурсів системи після успішного проходження ними автен- тифікації. Найчастіше процедури автенти- фікації й авторизації поєднують. За допо- могою авторизації встановлюються й реа- лізуються права доступу до ресурсів. Створення облікового запису кори- стувача у MediaWiki означає, що цей кори- стувач вказує ім'я облікового запису (ло- гін) і пароль. Для наступного входу корис- тувачу потрібно вказати логін і знову підт- вердити пароль. Для перегляду будь-якого відкрито- го Wiki-ресурсу на основі MediaWiki авто- ризація не потрібна. Як правило, вона не потрібна й для того, щоб редагувати кон- тент. Проте доступ з авторизацією надає користувачу кілька важливих переваг. Інші користувачі зможуть довідатися про діяль- ність користувача (зміни, внесені у сторін- ки) за логіном користувача. Це зручніше, ніж використання для цього IP-адреси ко- ристувача, яка може змінюватися, якщо користувач заходить до Wiki-ресурсу з різних пристроїв та місць. Спрощується спілкування з іншими користувачами Wiki-ресурсу, простіше відслідковувати зміни в цікавлячих сторінках, використо- вуючи список спостереження, та виникає можливість отримувати автоматичні по- відомлення про важливі події. Незважаючи на те, що технологія Wiki орієнтована на розробку відкритих джерел інформації, в процесі функціюван- ня таких ресурсів виникає потреба у захис- ті деяких фрагментів даних від несанкціо- нованого доступу. Зазвичай виникає необ- хідність закривати деякі певні сторінки, які містять конфіденційну бізнес-інформацію або є частиною робочого процесу устано- ви, що розробляє відповідний Wiki-ресурс. Це викликано як потребою у захисті персональних даних, так і доцільністю закриття технічних деталей реалізації від кінцевих користувачів. Зважаючи на відкриту ідеологію Wiki-систем, відповідні механізми в базо- вій версії MediaWiki відсутні. Існуючі плагіни, розроблені для цього сторонніми розробниками або мають лише бета- версію, або взагалі вже не підтримуються і є застарілими. Тому необхідно, використо- вуючи існуючі технологічні засоби сере- довища MediaWiki, створити механізм, який забезпечить захист елементів контен- ту Wiki-ресурсу для різних груп користу- вачів цього ресурсу. Додатковою умовою є максимальна незалежність такого рішення від оновлення версій ПЗ, гнучкість і прос- тота його використання. Постановка задачі Враховуючи існуючу архітектуру системи і принцип відкритості Wiki- ресурсу, необхідно створити технічне рі- шення – надбудову над системою, яка не змінить кардинально код системи, буде логічним і простим у використанні, але дозволить диференціювати доступ до ін- формації для різних категорій користува- чів відкритого Wiki-ресурсу відповідно до їх ролей, повноважень та інформаційних потреб. Для вирішення такої задачі пропо- нується: виконати семантичний поділ кон- тенту (сторінок, що складають Wiki- ресурс) на окремі множини, що не перети- наються, відповідно до їх функцій та типу вмісту, використовувати механізм розпо- ділу контенту за просторами імен, який існує в WikiMedia; розробити механізм пе- рехвату інформації, що згенерована на сервері системою, яка буде враховувати знання про цей розподіл та пов’язані з ним правила обробки для того, щоб передавати на клієнт тільки ті відомості, які є дозво- леними для цієї групи користувачів. Алгоритм керування доступом до контенту Wiki-ресурсу У найбільш узагальненому розумін- ні, для рішення проблеми керування досту- пу до контенту містить такі підзадачі: Моделі та засоби систем баз даних і знань 42 - розподіл користувачів на групи доступу відповідно до їх прав доступу до окремих елементів контенту (наприклад, на зареєстрованих і незареєстрованих); - розподіл контенту на групи (з використанням таких механізмів MediaWiki, як простори імен та категорії, а також семантичного розширення Semantic MediaWiki – семантичних властивостей сторінок та їх значень); - створення шаблонів типових інформаційних об’єктів (ТІО), що опису- ють ті дані, доступ до яких має бути дифе- ренційованим для користувачів з різних груп доступу; - розробка правил співставлення належності користувача до певної групи доступу з тим, яку саме інформацію він має право отримувати; - реалізація механізму для отри- мання набору даних, що доступні для кон- кретного користувача, що надає можли- вість аналізувати згенерований контент перед відправкою його на клієнт; - створення шаблонів для подан- ня інформації відповідно до аналізу, що виконано у попередньому пункті. Розглянемо окремі випадки реаліза- ції цього підходу. Для таких випадків про- понується використовувати механізм роз- поділу контенту за просторами імен, що існує в WikiMedia, і розробити механізм перехоплення інформації, що згенерована на сервері системою, яка буде передавати на клієнт тільки те, що дозволено. У загальному випадку з урахуван- ням специфіки MediaWiki, що проаналізо- вана вище, вхідними даними задачі є: - розподіл користувачів на зареє- строваних і незареєстрованих; - поділ контенту на різні просто- ри імен та категорії (та можливість додава- ти до сторінок певні шаблони); - можливість додавати програм- ний код, здатний аналізувати контент, зге- нерований MediaWiki, перед відправкою даних на клієнт. Архітектура Wiki побудована таким чином, що на останньому етапі перед відп- равкою згенерованої сторінки вона оброб- люється на рівні скіна. На цьому етапі мо- жливо додати до інформації певні html- теги, а також зробити більш глибокий ана- ліз контенту. Найбільш простим є аналіз простору імен, до якого відноситься сторі- нка, що аналізується. Скін Foreground програмно реалізо- вано двома класами: class Skinforeground, який розширює базовий клас ядра SkinTemplate і клас формату подання – class foregroundTemplate, який розширює BaseTemplate. Разом такий формат відображення і весь програмний код скінів подано в файлі типу Назва Скіну.skin.php. [11]. Розробка власного скіну надає мож- ливість вносити такі операції аналізу, не впливаючи на ядро MediaWiki. Внаслідок цього виникає можливість аналізувати контент відповідно до набору обраних умов та згенерувати новий контент відпо- відно до власних потреб. Узагальнений алгоритм роботи та- кого скіну містить наступні етапи: - формування сторінки контен- том згідно отриманих параметрів ядром Wiki в змінній $body; - аналіз змісту змінної $body і внесення змін відповідно до прав користу- вача і правил доступу; - відображення змінної $body в браузері. Перевірка, чи зареєстрований кори- стувач, здійснюється методом – $isLoggedIn = $wgUser->isLoggedIn(). Отримання простору імен поточної сторінки, здійснюється методом: $namespace = $this->getSkin()->getTitle()->getNsText(); Інші параметри сторінки отримуються від- повідно. Виконання перевірки та отримання дозволу виконується функцією $allow_to_ show = check_allow_to_show_content ($isLoggedIn, $namespace, $isArticle, $title, $content). Ця функція працює за наступною логікою: if ($allow_to_show == 1), зміна контенту згідно з правилами показу else зміна контенту згідно з правилами. Моделі та засоби систем баз даних і знань 43 Функція визначення дозволу має наступний вигляд: function check_allow_to_show_content($isLoggedIn, $namespace, $isArticle, $title, $content) { $allow_to_show = 1; if ($isLoggedIn != 1) { if($namespace=="ХХХХ") $allow_to_show = 0; elseif ($isArticle) { $allow_to_show = check_page_edition_status($vue_content); } } return $allow_to_show; } Функція check_page_edition_status ($content) аналізує контент статті (сторін- ки) і визначає дозвіл на показ чи редагу- вання поточної сторінки для певного кори- стувача. Таким чином, підключення аналіза- тору до скіну дозволяє проаналізувати сторінку і надати користувачеві тільки ту інформацію, яку можна показувати саме йому. Таке рішення не змінює основного ядра ПЗ, не залежить від версії ПЗ і дозво- ляє безболісно встановлювати оновлення ядра і додаткових плагінів. Можливість MediaWiki семантично розділяти контент шляхом використання механізму категорій та просторів імен на- дає багато інших можливостей і переваг для створення енциклопедичного контенту та корпоративних інформаційних ресурсів, тому що це забезпечує не тільки відобра- ження контенту, але й інтеграцію цієї сис- теми в робочий процес підприємства. Запропоноване рішення надає більше мо- жливостей для використання MediaWiki не тільки як базу знань, але й як допоміжну довідкову систему для керування внутріш- ніх корпоративних бізнес-процесів доку- ментообігу. Важливо зазначити, що запропоно- ване рішення не стосується захисту досту- пу до API MediaWiki та від різних типів хакерських атак тощо. Використання методу керування доступом в е-ВУЕ Запропонований вище підхід вико- ристовується для розширення функціоналу портальної версії Великої української ен- циклопедії (е-ВУЕ). Наразі структура БЗ е-ВУЕ формально зафіксована за допомо- гою відповідної Wiki-онтології, яка є ре- зультатом співпраці експертів ПрО (у да- ному випадку – модераторів галузей знань, що представлені в енциклопедії) з інжене- рами із знань. Для складної структури знань, що характерна для е-ВУЕ, це дозво- ляє значно чіткіше описувати знання та за- побігати повторного використання імен ка- тегорій з різними значеннями [12] та імпор- тувати знання з інших онтологій [13]. Проаналізувавши структуру БЗ, ми виділили наступні простори імен, які пот- ребують спеціалізованої обробки з точки зору доступу до параметрів сторінок: - шаблон; - подія; - артефакт; - зображення; - медіафайли; - аудіосупровід; - модератор. Кожен з цих просторів імен має специфічне призначення в е-ВУЕ і має використовуватися тільки розробниками ресурсу у службових цілях. Наприклад, простір імен Артефакт забезпечує виве- дення на першу сторінку порталу відомос- тей про ті артефакти, створення яких пов’язано з поточною датою. Інший приклад – шаблони виведен- ня інформації про типові елементи контен- ту е-ВУЕ. Доступ до таких шаблонів ма- ють отримувати тільки розробники цього ресурсу, автори та модератори наукових напрямків (рис. 3). Цей шаблон “Персоналія” призначе- ний для опису типових інформаційних об’єктів, пов’язаних з конкретними особа- ми, – персоналій. За допомогою цього шаб- лону забезпечується уніфіковане подання інформації про осіб на тих сторінках Wiki- ресурсу, що їм відповідають. Користувачі е-ВУЕ, що не автори- зовані, не отримують доступ до цього ша- блону. Тому контент таких сторінок буде схованим від них за допомогою розгляну- тих вище засобів (рис. 4). Моделі та засоби систем баз даних і знань 44 Рис. 3. Шаблон е-ВУЕ “Персоналія” та приклад його використання Рис. 4. Відмова у доступі до контенту сторінки шаблон е-ВУЕ “Персоналія” Моделі та засоби систем баз даних і знань 45 Висновки Розглянуто перспективи та область застосування Wiki-технологій, проаналізо- вано структуру подання контенту та про- грамне забезпечення MediaWiki. Запропо- новано абстрактну модель архітектури MediaWiki, яка формалізує відношення між основними складовими цього техноло- гічного середовища. Визначено проблему, що пов’язана з необхідністю керування доступом до контенту Wiki-ресурсів від- повідно до специфіки інформації, що міс- титься у таких ресурсах. Результати аналі- зу показали, що базові засоби MediaWiki не дозволяють отримати задовільне рішен- ня цієї задачі. Тому виникає потреба у створенні спеціалізованого програмного забезпечення, яке базується на класифіка- ції контенту з використанням окремих просторів імен, категорій, шаблонів та се- мантичних властивостей. які здобуваються з MediaWiki, та є незалежним від ядра MediaWiki, а базується на програмуванні аналізу контенту на рівні скіну. Наведене рішення апробовано у ро- зробці порталу е-ВУЕ [14] і використовує знання щодо структури бази знань цього порталу. Література 1. MediaWiki. https://www.mediawiki.org/ wiki/MediaWiki 2. Гришанова І.Ю., Рогушина Ю.В. Адапта- ція технологічних засад semantic mediawiki до потреб онлайн-версії великої українсь- кої енциклопедії ВУЕ. Традиції та сучасні концепти енциклопедичної справи в Украї- ні: колективна монографія / За ред. Кири- дон А.М. К.: Державна наукова установа «Енциклопедичне видавництво», 2018. С. 240–253. https://ev.vue.gov.ua/wp-content/ uploads/ 2019/11/Traditions.pdf 3. Leuf B., Cunningham W. The Wiki way: collaboration and sharing on the Internet, 2001, http://www.citeulike.org/group/ 13847/article/7659081. 4. Wikipedia – https:// www. wikipedia.org. 5. Рогушина Ю.В., Прийма С.М., Строкань О.В. Створення та використання семанти- чних Wiki-ресурсів: навчальний довідник. Мелітополь, ФОП Однорог Т.В., 2017. 169 с. 6. Manual: What is MediaWiki? https://www.mediawiki.org/wiki/Manual: What_is_MediaWiki%3F. 7. Brown A., Wilson G. The Architecture of Open Source Applications: Elegance, Evolution, and a Few Fearless Hacks, V. 1, 2011. ftp://188.235.129.151/ incoming/books/Wilson%20G.%20- %20The%20Architecture%20Of%20Open%2 0Source%20Applications%20-%202011.pdf. 8. Manual: Skins. https://www.mediawiki. org/wiki/Manual:Skins. 9. Magnus Manske. https://en.wikipedia.org/ wiki/Magnus_Manske 10. Авторизація. https://uk.wikipedia.org/ wiki/Авторизація 11. Документація для розробників скінів https://www.mediawiki.org/wiki/Manual:Skin ning_Part_2 12. Рогушина Ю.В., Гришанова І.Ю. Онтоло- гічна модель бази знань онлайн-версії «Великої української енциклопедії» та ме- тоди її застосування для семантичного пошуку та навігації. Енциклопедичний контент і виклики сучасного світу: Збірник матеріалів наукової конференції / За ред. Киридон А.М. К.: Державна наукова уста- нова «Енциклопедичне видавництво», 2019. С. 69–74. 13. Гладун А.Я., Рогушина Ю.В. Репозитории онтологий как средство повторного испо- льзования знаний для распознавания ин- формационных объектов. Онтология прое- ктирования. 2013. № 1 (7). С. 35–50. 14. Велика українська енциклопедія. https://vue.gov.ua/ References 1. MediaWiki. https://www.mediawiki.org/ wiki/MediaWiki 2. Grishanova I.Y, Rogushina J.V. (2018) Adaptation of technological means of Semantic Mediawiki for needs of online version of Great Ukrainian Encyclopedia // Encyclopaedias in Ukraine: people, ideas, steps: collective monograph / Ed. Kyrydon A.M., Kyiv, P.240-253. [in Ukrainian] 3. Leuf B.,Cunningham W. (2001) The Wiki way: collaboration and sharing on the Internet, 2001, http://www.citeulike.org/ group/13847/article/7659081. 4. Wikipedia. https:// www. wikipedia.org. 5. Rogushina Y.V., Priyma S.M, Strokan O.V. (2017) Creating and use of the Semantic Wiki https://www.mediawiki/ https://www.mediawiki.org/wiki/Manual:Skinning_Part_2 https://www.mediawiki.org/wiki/Manual:Skinning_Part_2 https://vue.gov.ua/ Моделі та засоби систем баз даних і знань 46 resources: tutorial. - Melitopol, FOP Odinorog T.V. – 169 p. [in Ukrainian] 6. Manual: What is MediaWiki? https://www.mediawiki.org/wiki/Manual:Wha t_is_MediaWiki%3F. 7. Brown A., Wilson G. (2011). The Architecture of Open Source Applications: Elegance, Evolution, and a Few Fearless Hacks (V. 1). – ftp://188.235.129.151/ incoming/books/Wilson%20G.%20- %20The%20Architecture%20Of%20Open%2 0Source%20Applications%20-%202011.pdf. 8. Manual: Skins. https://www.mediawiki. org/wiki/Manual:Skins. 9. Magnus Manske. https://en.wikipedia.org/ wiki/Magnus_Manske. 10. Avtorization. https://uk.wikipedia.org/ wiki/Авторизація. 11. Documentation for skin developers. – https://www.mediawiki.org/wiki/Manual:Skin ning_Part_2. 12. Grishanova I.Y, Rogushina J.V. (2019) Ontological model of online version of Great Ukrainian Encyclopedia knowledge base and methods of its use for semantic search // Encyclopaedic content and challenges of modern world / Ed. Kyrydon A.M., Kyiv. P. 64–74. [in Ukrainian] 13. Gladun A., Rogushina J. Ontology repositories as a means of knowledge reusing for recognition of information objects // Ontology for Design. 2013. N 1 (7). P. 35–50. [in Russian] 14. Great Ukrainian Encyclopedia, https://vue.gov.ua/ Одержано 05.02.2020 Про авторів: Гришанова Ірина Юріївна, науковий співробітник. Кількість наукових публікацій в українських виданнях – 19. Кількість наукових публікацій в зарубіжних виданнях – 3. http://orcid.org/0000-0003-4999-6294, Рогушина Юлія Віталіївна, кандидат фізико-математичних наук, старший науковий співробітник. Кількість наукових публікацій в українських виданнях – 155. Кількість наукових публікацій в зарубіжних виданнях – 31. http://orcid.org/0000-0001-7958-2557. Місце роботи авторів: Інститут програмних систем НАН України, 03181, Київ-187, проспект Академіка Глушкова, 40. Тел.: 066 550 1999. E-mail: ladamandraka2010@gmail.com, i26031966@gmail.com https://www.mediawiki.org/wiki/Manual:Skinning_Part_2 https://www.mediawiki.org/wiki/Manual:Skinning_Part_2 mailto:ladamandraka2010@gmail.com mailto:i26031966@gmail.com

Схожі ресурси