Specialized search engine system of scientific materials in Ukrainian language with social aspects
The paper describes the architecture of search engine scientific materials in Ukrainian language with the social component. Considered and the choice of technologies to develop a system described by its functionality. The algorithm for the selection scientific articles logical parts in the PDF docum...
Збережено в:
| Дата: | 2025 |
|---|---|
| Автор: | |
| Формат: | Стаття |
| Мова: | Ukrainian |
| Опубліковано: |
PROBLEMS IN PROGRAMMING
2025
|
| Теми: | |
| Онлайн доступ: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/725 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Репозитарії
Problems in programming| id |
pp_isofts_kiev_ua-article-725 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/78/6831dc666d377bd1ad54a500d9284478.pdf |
| spelling |
pp_isofts_kiev_ua-article-7252025-04-09T22:22:32Z Specialized search engine system of scientific materials in Ukrainian language with social aspects Пошукова система наукових матеріалів українською мовою із соціальною складовою Glybovets, A.M. UDC 004.8 УДК 004.8 The paper describes the architecture of search engine scientific materials in Ukrainian language with the social component. Considered and the choice of technologies to develop a system described by its functionality. The algorithm for the selection scientific articles logical parts in the PDF documents.Prombles in programming 2014; 2-3: 303-217 Описується архітектура пошукової системи наукових матеріалів українською мовою із соціальною складовою. Розглянуто та обґрунтовано вибір технологій для створення такої системи, описано її функціональність. Представлено алгоритм для виділення з PDF документів наукових статей логічних частин.Prombles in programming 2014; 2-3: 303-217 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-04-09 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/725 PROBLEMS IN PROGRAMMING; No 2-3 (2014); 312-317 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2-3 (2014); 312-317 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2-3 (2014); 312-317 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/725/777 Copyright (c) 2025 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2025-04-09T22:22:32Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
UDC 004.8 |
| spellingShingle |
UDC 004.8 Glybovets, A.M. Specialized search engine system of scientific materials in Ukrainian language with social aspects |
| topic_facet |
UDC 004.8 УДК 004.8 |
| format |
Article |
| author |
Glybovets, A.M. |
| author_facet |
Glybovets, A.M. |
| author_sort |
Glybovets, A.M. |
| title |
Specialized search engine system of scientific materials in Ukrainian language with social aspects |
| title_short |
Specialized search engine system of scientific materials in Ukrainian language with social aspects |
| title_full |
Specialized search engine system of scientific materials in Ukrainian language with social aspects |
| title_fullStr |
Specialized search engine system of scientific materials in Ukrainian language with social aspects |
| title_full_unstemmed |
Specialized search engine system of scientific materials in Ukrainian language with social aspects |
| title_sort |
specialized search engine system of scientific materials in ukrainian language with social aspects |
| title_alt |
Пошукова система наукових матеріалів українською мовою із соціальною складовою |
| description |
The paper describes the architecture of search engine scientific materials in Ukrainian language with the social component. Considered and the choice of technologies to develop a system described by its functionality. The algorithm for the selection scientific articles logical parts in the PDF documents.Prombles in programming 2014; 2-3: 303-217 |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2025 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/725 |
| work_keys_str_mv |
AT glybovetsam specializedsearchenginesystemofscientificmaterialsinukrainianlanguagewithsocialaspects AT glybovetsam pošukovasistemanaukovihmateríalívukraínsʹkoûmovoûízsocíalʹnoûskladovoû |
| first_indexed |
2025-07-17T09:37:26Z |
| last_indexed |
2025-07-17T09:37:26Z |
| _version_ |
1850412973407862784 |
| fulltext |
Прикладне програмне забезпечення
© А.М. Глибовець, 2014
312 ISSN 1727-4907. Проблеми програмування. 2014. № 2–3. Спеціальний випуск
УДК 004.8
ПОШУКОВА СИСТЕМА НАУКОВИХ МАТЕРІАЛІВ
УКРАЇНСЬКОЮ МОВОЮ ІЗ СОЦІАЛЬНОЮ СКЛАДОВОЮ
А.М. Глибовець
Національний університет «Києво-Могилянська академія»,
04655, Київ, вул. Г. Сковороди, 2.
Тел.: 425 0245, факс.: 425-02-45.
E-mail: andriy@glybovets.com.ua
Описується архітектура пошукової системи наукових матеріалів українською мовою із соціальною складовою. Розглянуто та обґрунто-
вано вибір технологій для створення такої системи, описано її функціональність. Представлено алгоритм для виділення з PDF докумен-
тів наукових статей логічних частин.
The paper describes the architecture of search engine scientific materials in Ukrainian language with the social component. Considered and the
choice of technologies to develop a system described by its functionality. The algorithm for the selection scientific articles logical parts in the PDF
documents.
Вступ
За умов інформаційного перенасичення сучасного суспільства надзвичайно важливими є фільтрування та
пошук релевантної інформації відповідно до потреб особи. Саме тому пошукові системи (ПС) набули такої популя-
рності. Однак ПС загального призначення нині уже недостатньо [1]. Для вирішення певних задач до наявних сис-
тем додаються уточнюючі функції, або ж створюються спеціалізовані системи: для пошуку за форматом файлів, за
певною категорією знань тощо. Одним з видів таких систем є ПС наукових матеріалів.
На сьогодні існує декілька потужних систем пошуку цього типу: Google Scholar, Scirus, ScienceDirect. Однак,
більшість з них не підтримує пошуку українською мовою, а інші не мають соціальної складової, яка б дозволила
користувачам системи спілкуватись між собою, обмінюватись інформацією, додавати нові матеріали, рецензії то-
що.
Зважаючи на ці зауваження, поставлено задачу розробки багатофункціональної моделі ПС наукових матеріа-
лів українською мовою з соціальною складовою (ПСНМУМ), а також реалізація алгоритму поділу документу на
логічні зони (заголовок, автор, використана література та УДК), що дозволить перейти до створення робочого
прототипу такої ПС.
Уточнимо постановку задачі. Окрім моделі потрібно: підібрати технології реалізації та обгрунтувати пере-
ваги і недоліки вибору; визначити список необхідних функцій системи, а також описати логіку їх реалізації; розро-
бити та реалізувати алгоритм для розбору матеріалів наукових статей у форматі PDF на логічні зони.
Архітектура та вибір технологій реалізації
Пошукова система наукових матеріалів складається з серверної та клієнтської частини.
Серверна частина містить спеціалізовані модулі, кожен з яких відповідає за окрему функцію пошукової сис-
теми, а саме: індексації, класифікації, збору посилань, клієнтський модуль (front end).
Клієнтська частина, разом із клієнтським модулем на сервері, відповідає за взаємодію з користувачем на сто-
роні клієнта. Вона надає доступ до функцій пошуку, обміну повідомленнями, соціальних функцій тощо і містить
інтерфейс для реєстрації та аутентифікації користувачів у системі.
При виборі технологій для реалізації проекту враховувалось кілька основних вимог до майбутньої системи:
масштабованість, ефективність, надійність. З огляду на вищезазначені вимоги, обрано такий стек технологій.
Серверна частина буде реалізована на мові Java. Серед переваг можна видылити: легкість у підтримці та ро-
звитку проекту; наявність рішень з відкритим кодом для організації пошукової системи (Hadoop, Lucene, Nutch,
Solr); наявність готових модулів, реалізованих силами автора роботи та інших студентів НаУКМА, що будуть ви-
користані для майбутнього проекту. Очевидним недоліком бачиться відносно низька швидкодія.
Для хостингу ми обираємо Google App Engine [2], а індексацію та основні функції інформаційного пошуку
будемо робити на базі бібілотеки Lucene [3]. Основними чинниками обрання останньої були висока швидкодія,
можливий пошук за полями (заголовок, автори), відкритий код і здатність індексувати PDF документи (більшість
наукових матеріалів саме в цьому форматі).
Проведення фронт-енду на сервері нам бачиться на базі JSF (JavaServer Faces) за можливості прямого досту-
пу до сервера (збільшує швидкодію) та наявності детальної документації.
Прикладне програмне забезпечення
313
Багата функціональність, велика кількість готових рішень широка спільнота розробників javascript/jQuery
визначила її обрання для клієнтської частини.
Функціональність системи
Початкова база документів для майбутньої пошукової системи буде відібрана з найпотужнішої на сьогодні
онлайн бібліотеки наукових матеріалів українською мовою – Національної бібліотеки України імені І. В. Вернадсь-
кого [4]. Надалі ця база поповнюватиметься за допомогою спеціального модуля (робота). Він діятиме за таким ал-
горитмом:
1) подібно до звичайних Web-браузерів, робот відвідує сторінку за посиланням і копіює її вміст;
2) в отриманому html-коді знаходить внутрішні та зовнішні посилання, шляхом пошуку входжень «http://»,
«href=» тощо. Отримані посилання робот вносить в базу даних;
3) виділяє серед html-коду власне текст, шляхом видалення усіх тегів та іншого не релевантного «сміття».
Отриманий текст зберігається для подальшого використання.
Окрім, робот має проводити циклічну перевірку уже доданих документів на наявність змін. З певним часо-
вим інтервалом, він має повторно відвідувати сторінки-джерела кожного документа. Якщо сторінка більше не до-
ступна, або матеріал за посиланням був видалений, робот має через деякий час видаляти посилання з бази системи.
Або ж, якщо контент сторінки змінився, він має проводити його повторну обробку, тобто знову копіювати вміст,
знаходити посилання та обробляти текст.
Очевидно, що для роботи даного модуля, адміністратор має створити початкову базу посилань на популяр-
ні наукові ресурси. Варто зазначити, що даний пункт не є обов’язковим для прототипу системи і може бути реалі-
зований пізніше, під час розширення системи.
Завдання індексації документів ми перекладаємо на бібліотеку Lucene. Вона надає широкий набір засобів
для створення інвертованого індексу. Ця бібліотека допускає розширення функціональності через перевизначення
функціональних одиниць. Розширюючи функціональність бібліотеки, розроблено клас ScientifícWorklndexator, що
відповідає за процес індексації [5].
Для створення індексу за зонами, необхідно мати інструмент для виділення окремих полів у документах (в
першу чергу імена авторів та назви статті). Основна проблема полягає у тому, що не існує єдиного стандарту для
оформлення документів, а тому така задача не є тривіальною. Алгоритм розбиття документа на логічні зони, а та-
кож його реалізацію представлено далі.
Завданням майбутньої пошукової системи є пошук саме наукових матеріалів. Тому перед індексацією доку-
мента, він має бути перевірений на науковість і за результатами цієї перевірки або доданий до бази, або відкинутий
як такий, що не відповідає вимогам системи і потребам користувача. Для цього буде використаний алгоритм, опи-
саний у [6].
Також кожен документ має бути віднесений до однієї або кількох категорій знань (зокрема для реалізації фу-
нкції пошуку за категоріями). Для вирішення цієї задачі буде використано підхід із [6].
Бібліотека Lucene здатна проводити зважене зонне ранжування, що і буде використовуватись у алгоритмі
пошуку майбутньої системи.
Система має надавати можливість пошуку статей за автором. Логіка реалізації даної функції відносно три-
віальна. Користувач повинен мати змогу при пошуку задавати ім’я автора/авторів, і отримувати у результатах пуб-
лікації вказаного автора/авторів. Також, при перегляді кожної статті, система повинна рекомендувати інші статті
того ж автора/авторів, якщо такі є. Оскільки імена авторів – це окрема зона індексу системи, ця функція є частково
реалізованою у бібліотеці Lucene.
У системі має бути реалізована функція пошуку документів за УДК та категорією/категоріями знань. Для
цього база системи має містити повний список категорій (зокрема, для виведення підказок під час пошуку). Також
кожен документ має бути віднесений до однієї або більше категорій під час класифікації. Як і пошук за автором, ця
функція є частиною зонного пошуку в Lucene.
Під час перегляду результатів пошуку та статей, користувачеві має надаватись рекомендації щодо схожих
матеріалів. Схожими вважатимуться матеріали, що мають спільного автора, спільні терміни в заголовку, спільні
джерела або ж належать до однієї категорії знань. Також має бути реалізована окрема функція пошуку, що дозво-
лить переглядати усі схожі статті до даної.
При перегляді певної статті користувач має мати можливість перейти до статей, що зазначені у списку поси-
лань до даної (якщо вони наявні у базі системи). Також має бути реалізована можливість переходу до статей авто-
рів, що зазначені у цьому списку.
Бувають випадки, коли різні автори працюють над однією темою, не здогадуючись про це. Система має до-
помогти таким користувачам знайти одне одного для подальшої співпраці. Для цього має бути реалізований модуль
обміну повідомленнями між користувачами. Має бути можливість вказування поточних тем діяльності користува-
чів (і відповідно їх перегляду). Роботодавцям або інвесторам, що шукають спеціалістів для виконання того чи іншо-
го завдання, система має запропонувати авторів, що працювали або працюють над відповідними темами. Має бути
реалізований пошук користувачів, що працюють за певною (або схожою) темою.
Прикладне програмне забезпечення
314
Якщо система набуде потрібної популярності, необхідно буде реалізувати можливість самостійного дода-
вання своїх робіт користувачами системи. Такий спосіб поповнення колекції має ряд переваг. Автор зможе чітко
зазначити атрибути своєї роботи при додаванні (назву, дату, використану літературу, категорію знань тощо), вод-
ночас як система могла зробити це з помилками.
Зареєстрованим користувачам системи має надаватись можливість оцінювати роботи інших користувачів. До
того ж, рейтинг статей автора має впливати на вагу його голосу при оцінюванні чужих статей. За допомогою таких
оцінок, має визначатись якість матеріалу, яка має враховуватись при видачі результатів на пошукові запити (при
ранжуванні документів).
Користувачі мають мати змогу визначати актуальність та цікавість обраної ними теми для інших користува-
чів. Зокрема, система надаватиме функціональність для зручного рецензування статей. Рецензії мають відобража-
тися поряд із самими статтями у результатах пошуку, що допоможе користувачам оцінити якість, повноту та відпо-
відність статті їх потребам ще до переходу на сторінку.
Розбір PDF-документів
Важливою частиною індексації та зваженого зонного ранжування наукових матеріалів у форматі PDF є їх ро-
збиття на логічні частини (зони). Для дослідження обрано саме формат PDF, оскільки на даний момент він є най-
популярнішим у сфері наукових публікацій. Крім того, база документів, що буде використовуватись у прототипі
системи, складається саме з матеріалів цього формату.
Основною проблемою розбору PDF документів є те, що цей формат не розрахований на програмну обробку.
Він орієнтований на відображення, а не на збереження та передачу текстової інформації. Крім того, не існує єдино-
го стандарту для оформлення наукових публікацій, і навіть тих стандартів, що розроблені, рідко дотримуються.
Наш алгоритм має виділяти у PDF документі такі зони: заголовок, УДК (універсальний десятковий класифі-
катор), автори та використана література (список посилань). Однак, є і інші важливі частини такі як: анотація, ви-
давництво, дата публікації, вступ тощо (ці зони в даній роботі не розглядатимуться).
Формат PDF (Portable Document Format) створено для представлення документів у незалежному від при-
строю виведення та роздільної здатності вигляді. Доступ до тексту та легкість програмного розбору не входили до
списку пріоритетів його розробки. Тому під час програмної обробки файлів цього формату виникають певні труд-
нощі. Файли формату PDF складаються з директив для відображення контенту, що не групуються за розташуван-
ням. Одне слово, або навіть буква, яку потрібно відобразити, може задаватися кількома директивами. Саме тому
першочерговою задачею під час програмної обробки PDF документів є виділення тексту та групування його за
абзацами.
Існує декілька готових бібліотек, що здатні виділяти текст з документів PDF (iText, PDFBox, PDF Clown), але
вони здебільшого подають текст сторінками і без форматування. Тому прийнято рішення розширити функціональ-
ність однієї з бібліотек (iText) [7] таким чином, щоб текст виділявся абзацами з однаковим або схожим формату-
ванням (розмір і жирність шрифтів, вирівнювання тексту тощо).
Реалізовано такий алгоритм:
● за допомогою бібліотеки iText виділяються окремі прямокутники з текстом.
● визначаються та об’єднуються прямокутники, що лежать в одному рядку. Два прямокутники вважаються
такими, що лежать в одному рядку, якщо їх вертикальний перетин складає не менше 80% висоти найнижчого з них.
Крім цього має виконуватись одна з умов: а) горизонтальна відстань між ними не має бути більшою, ніж висота
найнижчого з них; б) простір між цими прямокутниками рядком нижче повинен містити текст.
● визначаються та об’єднуються рядки, що належать до одного абзацу. Два рядки вважаються такими, що
належать до одного абзацу, якщо виконуються такі умови:
1) жирність шрифтів в обох рядках однакова;
2) регістр символів цих рядків однаковий;
3) нехай:
l – горизонтальна відстань між лівими краями рядків,
r – горизонтальна відстань між правими краями рядків,
c – горизонтальна відстань між центральними точками рядків,
w – максимальна ширина пробілу шрифтів обох рядків (white space width),
,, – деякі додатні константи.
Тоді виконується твердження:
)()( wcwrwl .
Експериментальним чином було підібрано: 1 , 5.1 , 5.4 ;
Прикладне програмне забезпечення
315
4) Вертикальна відстань між рядками не перевищує половину висоти лінії (line height) верхнього рядка.
Алгоритм поділу на логічні зони включає виділення заголовку, УДК, авторів та посилань.
Нехай X – множина абзаців першої сторінки документу; xfont – нормалізований розмір шрифта абзацу x
(тут і надалі Xx ); xlineheight – нормалізована висота лінії абзацу x ; xcentered – 1, якщо текст абзацу x відцен-
трований, 0 – якщо ні; xbold – 1, якщо шрифт абзацу x жирний, 0 – якщо ні; xuppercase – 1, якщо абзац x верх-
нього регістру, 0 – якщо ні;
Визначимо функцію:
ucuppercasebcboldcccenterdlclineheightfcfontxh xxxxx )( ,
де ucbccclcfc ,,,, – певні константи.
Заголовком статті вважатимемо текст того абзацу, для якого функція h прийматиме найбільше значення.
Експериментальним шляхом підібрано такі значення констант:
25.0,1,75.0,1,1 bcuccclcfc .
Пошук УДК зводиться до знаходження першого (за розташуванням зверху вниз, зліва направо) абзацу пер-
шої сторінки документа, текст якого починається з літер “УДК” та містить крім них лише цифри та знаки “-” і “.”.
Визначення авторів статті зводиться до знаходження абзацу, найближчого за розташуванням до абзацу заго-
ловку, що містить текст формату “І.І. П” або “П І.І.”, де І – ініціали, П – прізвище. Для цього створено окремі регу-
лярні вирази для кожного формату.
Пошук списку посилань полягає у знаходженні нумерованого списку, що починається з певних ключових
слів (“Використана література”, “Список посилань” тощо) на одній із останніх сторінок документа. Алгоритм про-
ходить по черзі сторінки документа, починаючи з останньої, доки не знайде абзац, що містить одне з ключових
слів. Знайшовши його, алгоритм за допомогою регулярних виразів виділяє нумерований список, що розташований
нижче цього абзацу. Якщо такого списку немає, продовжується пошук абзацу з ключовими словами.
Далі приведемо UML діаграму класів реалізації алгоритму (рис. 1, 2, 3).
Рис.1. діаграма класів: package guess
Прикладне програмне забезпечення
316
Рис. 2. Діаграма класів: package guess
Рис. 3. Діаграма класів: package tests, visualization
Прикладне програмне забезпечення
317
Висновки
В даній роботі представлено архітектуру пошукової системи наукових матеріалів українською мовою з соці-
альною складовою. Запропоновано таку структуру та технології для реалізації, за допомогою яких можна розроби-
ти масштабовану, ефективну та надійну систему.
Запропоновано та реалізовано алгоритм виділення у PDF документах наукових статей чотирьох основних
логічних зон. Описано сильні та слабкі сторони алгоритму. Проведений статистичний аналіз експериментальних
випробувань реалізації алгоритму показали його практичну придатність, хоча втручання експертів для перевірки
даних на перших етапах буде необхідно.
1. Глибовець М.М., Жигмановський А.А., Заболотний Р.І., Захоженко П.О. Веб сервіси оброблення документів, Національний університет
"Києво-Могилянська академія". – К.: НаУКМА, – 2012. – 212с.
2. Google App Engine https://developers.google.com/appengine/
3. Apache Lucene http://lucene.apache.org/core/
4. Національна бібліотека України імені В.І. Вернадського http://nbuv.gov.ua/
5. Глибовець А.М., Сітмамбетов Н. Создание специализированной поисковой системы на базе облачных технологий // Пр. міжнар. конф.
KDS 2012 “Knowledge-Dialog-Solution” 10-14 вересня 2012.
6. Глибовець А.М., Шабінський А.С., Ольшевський Р.Я. Побудова пошукового робота україномовних наукових матеріалів // Наукові праці
МДУ ім. Петра Могили. Комп’ютерні технології. – Випуск 130. – Том 143, – 2010. – С. 81–87.
7. ITEXT Programmable PDF Software http://itextpdf.com/
https://developers.google.com/appengine/
http://lucene.apache.org/core/
http://nbuv.gov.ua/
http://itextpdf.com/
|