Онтологічне моделювання предметної області з проблематикою e-scienсe

Розглядається проблема застосування результатів онтологічного моделювання предметних областей з проблематикою e-Science для побудови e-інфраструктур інформаційно-технологічної підтримки ведення науково-дослідних робіт. Розглянуті найбільш визначальні аспекти використання інструментарію Protégé для...

Full description

Saved in:

Bibliographic Details
Date:	2011
Main Author:	Зінькович, В.М.
Format:	Article
Language:	Ukrainian
Published:	Інститут програмних систем НАН України 2011
Subjects:	Інформаційні системи
Online Access:	http://dspace.nbuv.gov.ua/handle/123456789/50968
Tags:	Add Tag No Tags, Be the first to tag this record!
Journal Title:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Cite this:	Онтологічне моделювання предметної області з проблематикою e-scienсe / В.М. Зінькович // Пробл. програмув. — 2011. — № 3. — С. 30-37. — Бібліогр.: 4 назв. — укр.

Institution

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	irk-123456789-50968
record_format	dspace
spelling	irk-123456789-509682013-11-08T03:08:42Z Онтологічне моделювання предметної області з проблематикою e-scienсe Зінькович, В.М. Інформаційні системи Розглядається проблема застосування результатів онтологічного моделювання предметних областей з проблематикою e-Science для побудови e-інфраструктур інформаційно-технологічної підтримки ведення науково-дослідних робіт. Розглянуті найбільш визначальні аспекти використання інструментарію Protégé для рішення цієї проблеми. Наведено приклад застосування Protégé щодо рішення зазначеної проблематики. 2011 Article Онтологічне моделювання предметної області з проблематикою e-scienсe / В.М. Зінькович // Пробл. програмув. — 2011. — № 3. — С. 30-37. — Бібліогр.: 4 назв. — укр. 1727-4907 http://dspace.nbuv.gov.ua/handle/123456789/50968 681.3.06 uk Інститут програмних систем НАН України
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
collection	DSpace DC
language	Ukrainian
topic	Інформаційні системи Інформаційні системи
spellingShingle	Інформаційні системи Інформаційні системи Зінькович, В.М. Онтологічне моделювання предметної області з проблематикою e-scienсe
description	Розглядається проблема застосування результатів онтологічного моделювання предметних областей з проблематикою e-Science для побудови e-інфраструктур інформаційно-технологічної підтримки ведення науково-дослідних робіт. Розглянуті найбільш визначальні аспекти використання інструментарію Protégé для рішення цієї проблеми. Наведено приклад застосування Protégé щодо рішення зазначеної проблематики.
format	Article
author	Зінькович, В.М.
author_facet	Зінькович, В.М.
author_sort	Зінькович, В.М.
title	Онтологічне моделювання предметної області з проблематикою e-scienсe
title_short	Онтологічне моделювання предметної області з проблематикою e-scienсe
title_full	Онтологічне моделювання предметної області з проблематикою e-scienсe
title_fullStr	Онтологічне моделювання предметної області з проблематикою e-scienсe
title_full_unstemmed	Онтологічне моделювання предметної області з проблематикою e-scienсe
title_sort	онтологічне моделювання предметної області з проблематикою e-scienсe
publisher	Інститут програмних систем НАН України
publishDate	2011
topic_facet	Інформаційні системи
url	http://dspace.nbuv.gov.ua/handle/123456789/50968
citation_txt	Онтологічне моделювання предметної області з проблематикою e-scienсe / В.М. Зінькович // Пробл. програмув. — 2011. — № 3. — С. 30-37. — Бібліогр.: 4 назв. — укр.
work_keys_str_mv	AT zínʹkovičvm ontologíčnemodelûvannâpredmetnoíoblastízproblematikoûesciense
first_indexed	2025-07-04T12:52:03Z
last_indexed	2025-07-04T12:52:03Z
_version_	1836720875329552384
fulltext	Інформаційні системи © В.М. Зінькович, 2011 30 ISSN 1727-4907. Проблеми програмування. 2011. № 3 УДК 681.3.06 В.М. Зінькович ОНТОЛОГІЧНЕ МОДЕЛЮВАННЯ ПРЕДМЕТНОЇ ОБЛАСТІ З ПРОБЛЕМАТИКОЮ e-SCIENСE Розглядається проблема застосування результатів онтологічного моделювання предметних областей з проблематикою e-Science для побудови e-інфраструктур інформаційно-технологічної підтримки веден- ня науково-дослідних робіт. Розглянуті найбільш визначальні аспекти використання інструментарію Protégé для рішення цієї проблеми. Наведено приклад застосування Protégé щодо рішення зазначеної проблематики. Вступ Проблематика e-Science визначаєть- ся перетином сфер інформаційних техно- логій та науки. Сьогодні активно розроб- люється, головним чином, один її аспект – виконання наукових та проектних робіт у рамках національного та інтернаціональ- ного співробітництва шляхом обчислю- вальних GRID-технологій. У даній роботі серед інших проблем e-Science, релевантних наведеній, обрано проблему інформаційно-технологічного (ІТ) забезпечення науково-дослідних робіт (НДР). Розробка і рішення проблеми базу- ється на використанні узагальненої онто- логічної моделі предметної області (ПрО), у ролі концептів якої подані проблема або задача користувача, метод її рішення, інструментальний засіб та технологія ін- струментальної підтримки методу, подані в моделі через типізовані специфікації. Усім перелікованим концептам поставлені у відповідність такі артефакти e-Science, як інформаційні, технологічні та інстру- ментальні ресурси Інтернет. Самі концепти ПрО відображені в цієї моделі через класи, а відношення між ними визначаються через їх атрибути або слоти. До основи методу створення моделі покладено побудову засобів взаємодії та інтеграції зазначених класів. Модель створюється як дерево графів та подається в одному з форматів мов – HTML, RDF, OWL та ін. Онтологічна модель, створена та- ким чином, подає собою Базу Знань (БЗ), яка править за узагальнений понятійний каркас взаємодії деякої множини арте- факттів ПрО, і в подальшому викори- стовується при побудові моделей проблем- них областей, які обумовлені тематичними категоріями проблематики користувачів моделі ПрО. Передумовою побудові та використанню проблемних областей є створення екземплярів певних класів мо- делі ПрО, які утворюють склад бази даних (БД) моделі. Екземпляри класів ідентифі- кують конкретні артефакти e-Science, ін- терпретуючи їх як компоненти повторн- ого використання (КПВ). Самі КПВ мають бути розташовані у будь-якому репозиторії або у мережі Інтернет. Головним призначенням БД моделі є отримання e-інфраструктури середови- ща ІТ-підтримки НДР користувача через набір запитів до цієї БД, які відбивають його вимоги щодо компонентів інфра- структури – тематичної категорії, пробле- матики, методичної та технологічно-ін- струментальної підтримки у вигляді впо- рядкованого набору посилань на артефак- ти, тобто конкретні КПВ. Слід відмітити, що в статті розгля- даються інформаційні онтологічні моделі ПрО, які визначають лише інформаційні та логічні зв’язки між різними типами КПВ, Інформаційні системи 31 необхідні для складання КПВ у конфігура- ції без їх подальшого застосування. Підхід апробовано на моделі ПрО ІТ-підтримки наукових досліджень. Рішен- ня на такій моделі подають собою інфор- маційні технології, адаптовані до конкрет- ної проблематики користувачів, мають вір- туальний характер і формуються виключ- но за привхідними критеріями користува- чів щодо тематичних категорій дослід- жень, постановок задач дослідження, вибо- ру методів їх рішення та інструментально- технологічною підтримки. Побудову та ап- робацію онтологічної моделі ПрО здійсне- но за допомогою онтологічного редактора PROTÉGÉ версії 3.46 [1, 2] . Основні концепції моделювання ПрО з проблематикою e-Science Взагалі концепції підходу до моде- лювання ПрО визначаються сутністю ПрО та метою використання моделі. У нашому випадку об’єктом відпрацьовування мето- дології моделювання обрана предметна область методологічної, технологічної і програмно-інструментальної підтримки НДР певних тематичних категорій. Базові концепти ПрО – це узагальнені типи арте- фактів, що визначені наступним чином: тематична категорія НДР; задача або проблема певної тема- тичної категорії; методологія вирішення задачі (тобто сукупність методів); програмно-інструментальний за- сіб підтримки методу; технологія інструментальної під- тримки методів. Усі ці концепти ПрО подані в моде- лі у вигляді класів, об’єднаних у дерево графа, коренем якого є клас, що відповідає тематичній категорії НДР, а ребра графа відбивають семантичні зв’язки між класами. Самі класи подані в онтологічній моделі Protégé через специфікації або дескриптори класів. Екземплярами класів мають бути артефакти e-Science, в ролі яких висту- пають ресурси повторного використання, а саме інформаційні та програмно-інстру- ментальні КПВ, конкретизовані згідно з визначенням концептів, що асоційовані з класами. Так, для обраної ПрО в ролі інформаційних КПВ виступають описи проблем або задач НДР, методології їх рішення та описи технологій застосування інструментальної підтримки цих методоло- гій, а в ролі програмно-інструментальних КПВ – ідентифікатори інструментів або URL (Uniform Resource Locator) – уніфіко- вані локатори ресурсів. Саме КПВ мають визначати кінцеву конфігурацію ІТ-підтри- мки конкретної НДР. Зв’язність моделі. Найбільш визна- чальними для моделювання ПрО є метод формування зв’язності моделі. Базові кон- цепти ПрО моделюються в Protégé у вигля- ді класів з атрибутами (слотами), які хара- ктеризують їх властивості та відношення між ними, що подаються через ієрархію спадкування класів та їх логічні зв’язки. Найбільш суттєвими для побудови моделі ПрО постають два типи зв’язку між класами: прямі зв’язки (direct relation- ships), що відбивають відношення ієрархії успадкування класів у вигляді Subclass- Superclass. Такі зв’язки реалізують, окрім усього іншого, принцип множинного успа- дкування класів, що дозволяє при побудові ієрархії класів виділяти відповідні Use Ca- ses, тобто варіанти використання цього класу в контекстах різної проблематики. Таким чином принцип множинного успад- кування класів можна використати при виділенні проблемних областей у моделі ПрО. Прикладом застосування принципу множинного успадкування може служити використання одного і того ж програмно- 32 інструментального засобу для вирішення задач різних тематичних категорій НДР. Це здійснюється шляхом з’єднання класів через слоти певного типу, прикладом яких можуть бути слоти з іменами вигляду belong-to (належить до) або produce_ something (виробляючий щось). Прикладом другого типу зв’язків можуть служити зв’язки, які фіксують від- ношення між класом, що подає програмно- інструментальний засіб, та класом, що по- дає технологію його використання. Для формування між класами зв’яз- ків другого типу Protégé подає слоти с ти- пами значень Instance або Class. Такі зв’яз- ки можна проінтерпретувати наступним чином: якщо клас А містить слот типу Class або Instance, який містить клас В з множини класів, допущених для слота, то ми кажемо, що клас В залежить від класу А. Наведені типи слотів можна проко- ментувати наступним чином: слоти типу Class. Значенням їх можуть бути суперкласи, та ні в якому разі власні підкласи. Так, якщо на стадії моде- лювання класу програмно-інструменталь- ного засобу, такому слоту надається як значення ім’я суперкласу Методологія, то на стадії створення екземплярів такого класу цей слот отримує як значення ім’я одного з підкласів суперкласу Методоло- гія, тобто (умовно) Метод 1, Метод 2,…, …, Метод N. слоти з типом значення екземп- ляр (Instance). Для таких слотів у стадії мо- делювання ПрО як джерело можливих значень вказується який-небудь клас. На стадії створення екземпляра класу з таким слотом останній отримує як значення ім’я одного з екземплярів прив’язаного до сло- та класу. Екземплярізація побудованої мо- делі ПрО. Як зазначено вище, викори- станню моделі ПрО передує створення екземплярів класів певних підмножин кла- сів моделі ПрО, що відбивають конкретну тематичну проблематику. Створення екземплярів класів та формування відношень (relations) між ек- земплярами класів здійснюється через ввід відповідних значень у слоти обраних кла- сів. Результатом створення екземплярів класів моделі ПрО стає формування моде- лі даних конкретної проблемної області користувача у формі БД. Рішення завдань користувача моделі ПрО. Простір рішень завдань ко- ристувача модельованого ПрО визнача- ється сформованою проблемною областю, а окреме рішення подає конфігурацію ар- тефактів e-Science, що становить інфра- структуру ІТ-підтримки НДР користувача. Сама інфраструктура складає собою упо- рядкований через логічні зв’язки набір КПВ певних типів. Для рішення такого завдання користувач формує набір запитів (queries) до БД, які містять його вимоги та потреби щодо функціональності та ефективності такої підтримки. Самі запити зберігаються у бібліотеці запитів (Query Library), при- пускаючи тим самим їх повторне викори- стання і за потребою – комбінування. Ре- зультати запитів подаються як в екранних форматах редактора Protégé, так і у вигляді текстових файлів. Запити не становлять частину ство- реної БД, а є засобом ідентифікації та формування визначеної конфігурації екзе- мплярів, виходячи з властивостей класів і слотів та з вимог користувача. Структура окремого запиту вигля- дає наступним чином: - Назва запиту – Ім’я класу – Ім’я слота – Меню критеріїв – Значення критерію, де - Назва запиту (Query name) стано- вить собою рядок довільного тексту, який уводиться користувачем; - Ім’я класу вибирається з меню – переліку класів моделі; Інформаційні системи 33 - Ім’я слоту вибирається через меню з переліком слотів обраного класу; - Меню критеріїв (Criteria menu) містить перелік критеріїв; - Значення критерію уводиться від- повідно з типом значення слота обраного класу. Перелік критеріїв меню критеріїв для слотів, найбільш специфічних для виз- начення зв’язності класів та екземплярів класів, виглядає наступним чином: для слота типу String: contain, does not contain, is, is not, begin with, end with; для слотів типів Integer и Float: is, is greater than, is less than; для слота типу Symbol: is, is not; для слота типу Class: contains, does not contain; та, подібним чином, для слота типу Instance: contains, does not contain. Ввід значення критерію для слота типу Instance дещо відрізняється від інших типів. Так як значення можна надавати: один з екземплярів класу, що вказаний в опису слота, або назву потрібного користувачу запита з Query Library. Як приклад, можна розглянути нас- тупну ситуацію. Запит «Методи моделю- вання ПрО, що мають максимальну кіль- кість мов форматування результатів» шукає екземпляри класу Method, значення слота ontoredactor якого є також резуль- татом запиту «Онторедактор, кількість мов форматування результатів яких більш ніж 2». Формально ці запити вигля- дають наступним чином: «Онторедактор, кількість мов фор- матування результатів яких більш ніж 2» – language_number – is greater than – 4 та «Методи моделювання ПрО з мак- симальною кількістю мов форматування результатів» – ontoredactor – contains – «Онторедактор, кількість мов форматуван- ня результатів яких більш ніж 2». Комбінування запитів. Простий запит базується на класі, слоті чи разом на обох. Комбінований запит подається через множину запитів, зв’язаних в одиничний, або через ланцюжок запитів. Це дозволяє обмежувати чи навпаки розширювати ре- зультати запитів шляхом комбінування де- кількох критеріїв. У разі випадку множи- ни запитів додатково постають такі мож- ливості: використання опції Match All вказує, що будь-який знайдений у БД екземпляр має задовольняти усім крите- ріям (перетинання або AND), специфіко- ваним у множині запитів; використання опції Match Any вказує, що знайдений у БД екземпляр має задовольняти у крайньому разі одному з критеріїв, специфікованих у множині запитів. Результатом одиничного запиту по- стає деяка підмножина екземплярів вка- заного в запиті класу, яка задовольняє за- даному критерію. Результатом множини запитів пос- тає деяка більш обмежена підмножина екземплярів зазначеного в запиті класу, що задовольняє сукупності критеріїв. Ланцюжок запитів задається для пошуку в БД сукупності екземплярів мно- жини класів, зазначених у зчеплених ком- понентах ланцюжка. Формування ланцюж- ка запитів виконується шляхом зчеплення окремих запитів через слоти типу Instance, значенням яких задається ім’я потрібного запиту з бібліотеки Query Library Protégé. Збережені у бібліотеці запити можна використовувати як пов’язуючи значення для слотів типу Instance. Резуль- туючий запит шукає екземпляри, у яких значення слота становить результат пошуку. Необхідність створення запитів та- кого типу виникає досить часто. Наприк- лад, з цією метою шукається клас, що має слот типу Instance, і виникає потреба ді- 34 знатись, які з екземплярів цього класу ма- ють певну властивість. Для створення ком- бінованого запиту треба спочатку створити запит для властивості, а потім створити запит для класу. Результати запиту експортуються у текстовий файл protégé_query_results.txt. За умовчанням, текстовий файл містить набір ідентифікаторів усіх екземплярів та їх класів. Крім того, при формуванні вихід- них результатів запитів користувач зазна- чає необхідність виводу значень потрібних йому додаткових слотів екземпляра. Приклад онтологічного моделювання в Protégé У цьому розділі розглянуто най- більш визначальні моменти реалізації під- ходу до онтологічного моделювання ПрО ІТ-підтримки НДР, що наведено у цій статті. 1. Базовим концептом, що обумов- лює вибір проблемної області, тобто під- моделі моделі ПрО, визначено тематичну категорію НДР. У ролі інших базових концептів визначені інформаційні, інфор- маційно-технологічні ресурси обраної ПрО, а саме – описи проблеми/задачі НДР, документи, релевантна література та ін- структивні матеріали щодо методів її рішення і засоби технологгічної та інстру- ментальної підтримки. 2. Тематичні категорії наукових досліджень організовані в ієрархічне дере- во тематичного класифікатора, верши- нам якого у моделі відповідають абст- рактні класи з іменами категорій, крім ко- реневого класу, що має ім’я Topics (рис. 1). InfoTechModel: Class Hierarchy • :THING o TOPICS ІНФОРМАТИКА Штучний Інтелект Математичне Моделювання Теорія Ігор Теорія Кодування ІНФОРМАЦІЙНІ ТЕХНОЛОГІЇ та ОС Інформаційні Ресурси та Системи Обробка та Аналіз Даних Системи Текстового Пошуку Засоби Побудови Електронних Бібліотек Фундаментальні Основи ІТ МАТЕМАТИКА Алгебра Векторний Аналіз Диференціальні Обчислення Топологія МЕХАНІКА Теоретична Механіка ФІЗИКА o PROBLEM/ TASK o METHOD o TOOL o URLReference Рис. 1. Ієрархія класів моделі предметної області Інформаційні системи 35 3. Іншим базовим концептам пос- тавлено у відповідність типові структури даних, визначені у вигляді конкретних класів з іменами Problem/Task, Method, Tool та URLReference. Дескриптори одного з них показано на рис. 2. 4. Класи (та екземпляри) моделі пов’язані між собою двома засобами – через принцип спадкування і побудови ієрархічного дерева та через з’ясування се- мантичних відношень між класами, які здійснюються через атрибути або слоти класів. Коренем ієрархічного дерева пра- вить системний клас Protégé - :THING (річ). 5. Семантичні зв’язки потенційно більш виразні та дозволяють аналізувати БД проблемної області більш змістовно (рис. 3). Граф, що відбиває зв’язки такого типу, дозволяє через досить складні запити отримувати замість окремих КПВ цілу низку КПВ, що становить шуканий ре- зультат. 6. Зв’язки, що формуються слота- ми першого типу, визначають семантичну належність екземплярів класу – власника слота до іншого класу, наприклад, екземп- ляр класу Problem/Task через значення слота sub_location має належати до певної тематичної категорії, яка відбивається одним з абстрактних класів тематичного класифікатора (рис. 3). 7. Відношення, що встановлю- ються слотами другого типу, визначають семантичний контроль екземпляра класу- власника слота над певною множиною (у загальному випадку) екземплярів зв’язан- ого класу. Наприклад, екземпляр класу Method через значення свого слота типа Instance визначає можливість використан- ня для своєї підтримки множини реле- вантних екземплярів класу Tool. 8. Зв’язки другого виду реалізовані через слоти типу Class, значеннями яких мають бути класи; і типу Instance, значен- нями яких мають бути екземпляри класів; та слотів, що формують інверсне відно- шення між екземплярами двох класів шля- хом зв’язування їх через слоти Instance. 9. Інверсний зв’язок між екземпля- рами пари класів, пов’язаних через слоти типу Instance, формується через визначен- ня для цих слотів обмежувачів ролі (фаце- тів). Значеннями цих фацетів мають бути вирази вигляду inverse-slot = <ім’я слоту зв’язаного класу>. Такий зв’язок взаємно синхронізує зміну значень слотів під час створення нових екземплярів цих класів. Template Slots Slot Name Documentation Type Cardinality method_name Стисле ім.’я Методу String 0:1 method_annotatation Анотований опис Метода String 0:1 problem_task Проблема/Задача, що вирішується за підтримки даного методу. Метод може підтримувати рішення декількох проблем Problem/Task 0:* sub_category_method Тематична категорія методу String 0:1 meth_keyword_list Список ключових слів {} 0:* method_documentation Список адрес документів по методу URLReference 0:* meth_relevant_info Список адрес джерел релевантної інформації URLReference 0:* tool_list Список інструментальних засобів підтримки методу Tool 0:* method_consultant URLReference 0:* Рис. 2. Class Method. Дескриптор класу Метод 36 Математика Тематичний класифікатор Фізика Інформаційні технології та ОС Інформатика Механіка . . . Клас PROBLEM / TASK Найменування задачи task_name Тематична категорія задачи sub_location Перелік методів methodology Клас METHOD Найменування методу method_name Найменування задачи problem_task Опис методу method_documentation Список інструментів tools_list Клас TOOL Найменування інструменту tool_name Метод, що підтримується method Документація tool_doc URL-адреса інструменту tool_download Клас URLReference Найменування посилання reeference_name URL-посилання на ресурс reference_URL Інформаційні ресурси і системи Обробка та аналіз даних Фундаментальні основи ІТ . . . Системи текстового пошуку Засоби побудови ЕБ . . . Рис. 3. Структура графа узагальненої моделі ПрО ІТ-підтримки НДР Висновки Якщо перші етапи розглянутої мето- дології автоматизувати важко, то всі інші, починаючи з формування та вводу запитів до БД проблемної області, становлять реа- льну перспективу автоматизації. Для переходу від інтерактивного формування та вводу запитів у БД проб- лемної області до автоматизованого найбі- льш ефективною і перспективною є орієнтація на розробку відповідного прог- рамного забезпечення мовами Java та SPARQL. Так SPARQL (SPARQL Query Language for Protégé) [3] подає собою мову запитів до даних, наведених за моделлю RDF, і може бути також використана до моделей у форматі RDF Schema і OWL. Ця мова забезпечує протокол для передачі цих запитів та відповідей на них і рекомендо- вана консорціумом W3C Working Draft як стандарт та одна з технологій семантичної павутини. Проте застосування мови SPARQL має свої вади, наприклад, SPARQL вбудо- ваний до Protégé версії не вище 3.2, і Protege 4 не підтримує запити на цій мові. Крім того, використання вбудованої до Protégé мови SPARQL, всупереч її позитивним якостям, має той же недолік – Інформаційні системи 37 її використання підтримується лише в інтерактивному режимі. Подолання цих вад SPARQL та автоматизація роботи з запитами на цій мові можливо через створення відповідних Java-застосувань. Застосований підхід використову- ється в інтегрованому середовищі генеру- ючого програмування на платформі Eclipse проекта «Розробка теоретичних основ генеруючого програмування, прикладних та інструментальних засобів його підтрим- ки» [4]. Цей підхід забезпечує подання компонентів повторного використання при описі моделей предметних областей різно- го призначення. В даному середовищі Eclipse підтримує формати RDF та OWL і запити SPARQL. 1. Protégé-Frames User’s Guide. http://protégé.stanford.edu/doc/frames/ 2. Protégé-OWL API Programmer’s Guide. http://protege.stanford.edu/doc/owl/guide.html 3. SPARQL Query Language for RDF. http://www.w3.org/TR/rdf-sparql-query/ 4. Лавріщева Е.М. Генерувальне програ- мування програмних систем і сімейств // Проблеми програмування. – 2009. – № 1. – С. 3–16. Отримано 10.05.2011 Про автора: Зінькович Валерій Митрофанович, провідний інженер-програміст. Місце роботи автора: Інститут програмних систем НАН України, 03187, Київ-187, проспект Академіка Глушкова, 40. Тел. 044 526 3098. e-mail: vmz45@ukr.net

Онтологічне моделювання предметної області з проблематикою e-scienсe

Institution

Similar Items