Рус Eng За 365 дней одобрено статей: 1943,   статей на доработке: 314 отклонено статей: 753 
Библиотека
Статьи и журналы | Тарифы | Оплата | Ваш профиль

Вернуться к содержанию

Обеспечение слабой связности экспертной системы и онтологической базы знаний путём добавления обслуживающего слоя
Рясков Андрей Сергеевич

аспирант, кафедра Математика и информационные технологии, Волгоградский государственный технический университет, Институт архитектуры и строительства

400074, Россия, Волгоградская область, г. Волгоград, ул. Академическая, 1, ауд. В-512

Ryaskov Andrey Sergeevich

post-graduate student of the Department of Mathematics and Information Technology at Volgograd State Technical University, Institute of Architecture and Civil Engineering

400074, Russia, Volgogradskaya oblast', g. Volgograd, ul. Akademicheskaya, 1, aud. V-512

andrew.ryaskov@gmail.com

Аннотация.

Цель исследования состоит в предложении метода и прикладных технологий, позволяющих уменьшить время адаптации конкретных баз знаний и экспертных систем друг к другу. Дана оценка текущей архитектурной реализации связи экспертных систем и баз знаний, рассмотрены недостатки — основным недостатком является необходимость переписывать слой сопряжения экспертной системы и базы знаний при любом изменении в протоколе обмена данными между ними, поставлена цель — снизить связность экспертной системы и базы знаний. Архитектура, основанная на слабой связи модулей в системе обширно применяется в других областях. Методами исследования являются методы программной инженерии, дескрипционной логики, инженерии знаний и численные методы. Реализация обслуживающего слоя проводится, исходя из требований к реализации клиент-серверных приложений. Сделано предположение о возможности использования слоя-посредника (обслуживающего слоя), обоснована новизна и эффективность данного подхода. Проведён анализ технологий, позволяющих абстрагироваться от формата данных, предоставляемых базой знаний. Принято решение использовать технологию GraphQL для обмена данными, а промежуточный слой реализовать в виде сервера (в терминах клиент-серверной архитектуры). Отмечается конкретное применение предложенного решения для экспертной системы экологической нагрузки города Волгограда. Внедрение обслуживающего слоя позволило облегчить взаимную адаптацию экспертных систем и баз знаний, уменьшило связность компонентов. В качестве работы на будущее предлагается внедрить в обслуживающий слой компонент для управления доступом и компонент для обслуживания неограниченного круга лиц, например, для предоставления данных об экологической нагрузке населению.

Ключевые слова: онтология, экспертная система, база знаний, архитектура слабосвязанных модулей, клиент-серверная архитектура, GraphQL, REST API, SOAP, OWL-обёртки, Пролог

DOI:

10.25136/2306-4196.2018.2.25804

Дата направления в редакцию:

24-03-2018


Дата рецензирования:

02-04-2018


Дата публикации:

23-04-2018


Abstract.

The aim of the article is to offer methods and applied technologies allowing to reduce the time of adapting knowledge bases and expert systems to one another. In his research Ryaskov gives an evaluation of the current connectivity architecture of expert systems and knowledge bases and analyzes drawbacks thereof, the main drawback being the need to rewrite the layer of conjunction of expert system and knowledge base whenever the data exchange protocol is changed. The author also sets a goal to reduce the connectivity between expert system and knowledge base. The architecture that is based on the weak connectivity architecture is extensively used in other fields. The research methods used by the author include the software engineering methods, descriptive logic, knowledge engineering and numerical methods. The service layer is exected based on the requirements set forth for client-service apps. As a result of his research, Ryaskov offers to use the mediation layer (service layer) and proves the novelty and efficiency of this approach. The author carries out an analysis of technologies allowing to abstract from data format provided by the knowledge base. The author decides that it is useful to apply the GraphQl technology for data exchange and the mediation layer should be used as a server (in terms of the client-server architecture). The author describes practical implementation of that decision for the expert system of the environmental load in Volgograd. Implementation of the service layer allowed to ease up the mutual adaptation of expert systems and knowledge bases and to reduce the component connectivity. As a prospect, the author offers to embed an access management component and general public service component into the servicelayer, for example, to provide data to the population about the environmental load. 

Keywords:

SOAP, REST API, GraphQL, client-server architecture, weak connectivity architecture, knowledge base, expert system, ontology, OWL-wrappers, Prolog

За последнее десятилетие увеличилась роль экспертных систем (ЭС) и баз знаний (БЗ) в промышленных процессах [1]. В дополнение к стандартным источникам наполнения баз знаний фактами — экспертов, в дело входят и другие — например, в области экологического мониторинга — это автономные экологические посты по всей России, с которых поступают данные о замерах контролируемых показателей. Эти данные обрабатываются в автоматизированном режиме и пополняют БЗ. Для эффективного наполнения БЗ особенно важно правильно структурировать входящую информацию. Одной из форм структурирования информации являются БЗ на основе онтологии (онтологической модели). Рассмотрим подробнее экспертные системы на основе онтологических БЗ. На рисунке 1 показана общая архитектура экспертной системы.

Рис. 1. Общая архитектура экспертной системы

Эксперт взаимодействует с БЗ, наполняя её и корректируя. БЗ может быть представлена в различных форматах — логика первого порядка, продукционные правила, в виде правил на основе дизъюнктов Хорна, дескрипционные логики. Именно дескрипционные логики получили широкое распространение в инженерии знаний в виде хранения знаний в онтологических БЗ. Основным форматом физического представления онтологии на сегодняшний момент является формат OWL (сокр. англ. Web Ontology Language — язык сетевых онтологий). Данный формат рекомендован Комитетом Всемирной паутины (W3C) для использования в онтологических БЗ, имеет широкую поддержку со стороны программных инструментов, в наличии имеется открытая и полная документация.

Блок логического вывода отвечает за анализ знаний и вывод новых знаний на основе правил вывода. Для вывода новых знаний используются специальные программные модули — машины вывода (англ. Reasoners).

Блок объяснения — блок, осуществляющий построение цепочки логически связанных фактов из БЗ для объяснения полученного ответа пользователю.

Блок общения обеспечивает взаимодействие логического модуля ЭС с пользователем и представляет информацию на понятном пользователю языке.

Эксперт — лицо, привлекаемое для наполнения БЗ. ЭС позволяет снизить нагрузку на эксперта за счёт взятия на себя части обязательств по предоставлению знаний пользователям.

Пользователь — лицо, которое желает получить поддержку в принятии решения в некоторой предметной области.

Рассмотрим подробнее участок соединения ЭС и БЗ.

Типовая схема взаимодействия ЭС (логического модуля ЭС) с онтологической БЗ формата OWL показана на рисунке 2. Здесь используется промежуточное программное обеспечение (англ. middleware) на основе программного интерфейса приложения (сокр. англ. API) OWL API [2].

Рис. 2. Взаимодействие логического блока ЭС с онтологической БЗ

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

Другим преимуществом является то, что OWL API практически не зависит от выбранного языка программирования — на практике программист может использовать одну из множества OWL-обёрток (англ. OWL API-wrappers) для доступа к OWL API.

Однако, существуют и недостатки. В частности, главный недостаток такой связки — плотная интеграция ЭС и БЗ. Если в будущем понадобится использовать другую ЭС с заполненной БЗ, либо подключить другую БЗ к существующей ЭС, возникают проблемы интеграции — необходимо переписать слой стыковки. Это влечёт за собой дополнительные расходы. Как частный случай, если планируется переход от OWL к KIF-онтологиям, OWL API больше не будет работать корректно, нужно будет переписывать модуль взаимодействия с БЗ [3].

В ходе научной работы, описываемой в настоящей статье, было проведено исследование, направленное на обеспечение слабой связности ЭС и БЗ на основе онтологических моделей.

Цель исследования — предложить метод и прикладные технологии, которые позволят уменьшить время адаптации конкретных БЗ к новым экспертным системам, либо наоборот — адаптации экспертных систем для различных БЗ.

Актуальность повышения интеграционной способности онтологической БЗ обусловлена тем, что в последнее время появляется всё больше экспертных систем на основе подобных БЗ, авторы которых разрабатывают собственных слой взаимодействия с онтологией [4]. Этот подход имеет такой недостаток как необходимость написания нового слоя взаимодействия каждый раз при изменении формата общения БЗ и ЭС.

В качестве посредника между ЭС и БЗ предлагается использовать обслуживающий (серверный, от англ. Server — обслуживающий) слой. Этот дополнительный слой свяжет клиент (ЭС) и сервер (БЗ). Клиент-серверная архитектура уже успешно работает в других областях, где требуется обеспечить слабую связанность компонентов информационной системы [2].

Новизна предлагаемого подхода заключается в том, что производится унификация взаимодействия экспертных систем с онтологическими базами знаний путём использования метода, который ранее не применялся в подобной области. Метрикой эффективности подхода примем количество времени, которое удалось сэкономить при отсутствии необходимости переписывания блока логического модуля под взаимодействие с новым типом (форматом) БЗ.

В ходе рассмотрения вариантов архитектурных стилей серверного слоя были изучены следующие:

- SOAP-слой

- REST-слой

- GraphQL-слой

SOAP (сокр. англ. от Simple Object Access Protocol — простой протокол доступа к объектам) является наиболее распространённым методом взаимодействия с сервером, доступно множество инструментов и библиотек для работы по SOAP [5]. Недостатками SOAP являются избыточность информации для обмена, в основном из-за использования языка разметки XML, а также снижение скорости обработки за счёт увеличения объёма передаваемых данных.

Пример ответа сервера на запрос в стиле SOAP:

<soap:Envelope>

<soap:Body>

<getPlantDetailsResponse>

<ID>325626< / ID>

<PlantName>ООО Завод специального оборудования< / PlantName>

<Description>Выпуск высокоточного оборудования, солнечных панелей.< / Description>

<Wastes>

<Solidwastes>

<Waste>

<ID>87645-1364 < / ID>

<Name>Бумага< / Name>

<DangerClass>4< / DangerClass>

<AmountT>5< / AmountT>

<IsRecyclable>true< / IsRecyclable>

< / Waste>

< / Solidwastes>

< / Wastes>

< / getPlantDetailsResponse>

< / soap:Body>

< / soap:Envelope>

REST-подход, пришедший на смену SOAP [6], обладает меньшей избыточностью информации вследствие использования языка разметки JSON. Ответы сервера зависят только от входных параметров (англ. stateless — без состояния). Недостатком REST можно считать необходимость описывать все возможные методы работы с данными на этапе программирования слоя абстракции. Также стоит отметить, что после того, как некоторые операции на онтологии станут бессмысленными, например, вследствие удаления части знаний из БЗ, в REST-слое всё равно останутся методы для работы с ними, в то время, если программист серверного части (БЗ) захочет изменить интерфейс обращения к знаниям (например, изменив сигнатуру некоторых методов), то это повлечёт за собой отказ некоторой части функциональности, которую реализуют ЭС, подключённые к через данный слой к БЗ. Стоит также заметить, что REST не совсем подходит для работы с большими массивами информации, из-за того, что при желании получить некоторый атрибут объекта из списка объектов БЗ, происходит обязательная загрузка полного объекта со всеми его атрибутами (свойствами), и только потом отделяются нужные пользователю свойства [7].

Пример ответа сервера на запрос по REST:

{

id: 325626,

plantName: «ООО Завод специального оборудования»,

description: «Выпуск высокоточного оборудования, солнечных панелей.»,

wastes: {

solidwastes: {

waste: {

ID: '87645-1364',

Name: 'Бумага',

DangerClass: 4,

AmountT: 5,

IsRecyclable: true

}

}

}

}

GraphQL решает проблему SOAP, уменьшая избыточность поступающих данных, а также проблему REST — позволяя уже на этапе запроса к серверу определять необходимые для выборки атрибуты и получать от сервера только их вместо целого объекта [8]. GraphQL является современной технологией с достаточной документацией и обеспеченностью программными модулями для реализации обмена данными по этому протоколу.

Архитектура сопрягающего модуля после внедрения серверного слоя представлена на рисунке 3.

Риc. 3. Архитектура системы взаимодействия ЭС-БЗ после внедрения серверного слоя

В новой версии архитектуры показана работа с OWL, KIF и Prolog-базами знаний. Предполагается, что в один момент времени будет использоваться лишь одна из них, хотя совместное использование не исключается. Несколько типов БЗ приведено для демонстрации независимости ЭС от типа БЗ при внедрении данного решения.

Блок онтологической абстракции является связующим звеном уровня API и GraphQL сервера. При передаче данных из БЗ, он формализует их на более высоком уровне и передаёт на сервер GraphQL. При передаче данных в БЗ, он преобразовывает формализованные данные на уровень ниже, в сущности, понятные конкретному онтологическому модулю (например, KIF [9]).

Описанный подход был применён на практике в виде разработанного серверного слоя для экспертной системы экологической нагрузки г. Волгограда [3].

Эффективность внедрения серверного слоя измеряется в объёме работы, которую не придётся совершать при смене БЗ или ЭС — написание программного слоя, обеспечивающего интероперабельность различных версий и типов ЭС и БЗ. Написание слоя взаимодействия логического модуля и БЗ может занимать около 160 часов с онтологической базой знаний, насчитывающей не более 1000 концептов [10]. 160 часов — это один человеко-месяц, который будет экономиться при внедрении описанного архитектурного подхода.

За счёт того, что вместе с серверным слоем БЗ фактически становится доступной «как сервис», открывается возможность публикации БЗ для неограниченного круга лиц (например, экологическая БЗ публикуется для населения), которые могут воспользоваться заранее известными методами доступа к знаниям через серверный слой и не зависеть от смены версий БЗ.

Итак, в статье был рассмотрен новый подход к обеспечению связи между логическим модулем ЭС и БЗ, обеспечивающий их слабую связность. В будущем планируется введение системы контроля прав доступа к БЗ, что позволит выделить роли и уровни доступа в системе, также намечен запуск онтологической БЗ на публичном веб-сервере для всеобщего доступа.

Библиография
1.
Санжапов Б.Х. Разработка процесса унификации представления данных результатов экологического мониторинга атмосферного воздуха // Санжапов Б.Х., Молодцова С.В., Рашевский Н.М., Синицын А.А // Известия ВолгГТУ. Сер. Актуальные проблемы управления, вычислительной техники и информатики в технических системах. 2017. № 8 (203). C. 78-81.
2.
Adamusiak T. et al. OntoCAT — simple ontology search and integration in Java, R and REST/JavaScript. BMC Bioinformatics journal. 2011. №12. С. 218-230.
3.
Санжапов Б. Х. Разработка онтологической модели экологической нагрузки города Волгограда [Электронный ресурс] // Санжапов Б. Х., Рясков А.С. // Интернет-вестник ВолгГАСУ. Сер.: Строительная информатика. 2014. Вып. 12(36). Ст. 3. URL: http://vestnik.vgasu.ru/attachments/3SanzhapovRyaskov-2014_12(36).pdf (дата обращения 6.03.2018)
4.
Grévisse C., Botev J., Rothkugel S. An Extensible and Lightweight Modular Ontology for Programming Education. Advances in Computing. Materials of the Colombian Conference on Computing. Cali, Colombia, September 19-22, 2017. no. 735. pp. 358-371.
5.
Лаврищева Е. М. Системная поддержка решения бизнес-задач в глобальной информационной сети // Лаврищева Е. М., Карпов Л. Е., Томилин А. Н. // Материалы XVII Всероссийской научной конференции Научный сервис в сети Интернет. Новороссийск, 2015. С. 193-218.
6.
Almeida J. et al. An Ontology and a REST API for Sequence Based Microbial Typing Data. Bioinformatics for Personalized Medicine, Berlin, 2012. no. 6620. pp. 21-28.
7.
Ed-Douibi, H., Izquierdo, J. L. C., Gómez, A., Tisi, M., & Cabot, J. EMF-REST: generation of restful apis from models. In Proceedings of the 31st Annual ACM Symposium on Applied Computing 2016. pp. 1446-1453.
8.
Калиниченко Г.А. Сравнение технологий GraphQL и REST API в разработке современных клиент-серверных приложений // Калиниченко Г.А., Скороход С.В. // Технические науки: проблемы и решения: сб. ст. по материалам III-IV Международной научно-практической конференции «Технические науки: проблемы и решения». № 3-4(3), Москва, 2017. С. 47-52.
9.
Codescu M., Mossakowski T., Kutz O. A categorical approach to networks of aligned ontologies. Journal on Data Semantics. no. 6(4). 2017. pp. 155-197.
10.
Burita L. Ontology Development as a Software Engineering Procedure. International Conference on Digital Information and Communication Technology and Its Applications. Berlin, 2011. no. 167. pp. 1-8.
References (transliterated)
1.
Sanzhapov B.Kh. Razrabotka protsessa unifikatsii predstavleniya dannykh rezul'tatov ekologicheskogo monitoringa atmosfernogo vozdukha // Sanzhapov B.Kh., Molodtsova S.V., Rashevskii N.M., Sinitsyn A.A // Izvestiya VolgGTU. Ser. Aktual'nye problemy upravleniya, vychislitel'noi tekhniki i informatiki v tekhnicheskikh sistemakh. 2017. № 8 (203). C. 78-81.
2.
Adamusiak T. et al. OntoCAT — simple ontology search and integration in Java, R and REST/JavaScript. BMC Bioinformatics journal. 2011. №12. S. 218-230.
3.
Sanzhapov B. Kh. Razrabotka ontologicheskoi modeli ekologicheskoi nagruzki goroda Volgograda [Elektronnyi resurs] // Sanzhapov B. Kh., Ryaskov A.S. // Internet-vestnik VolgGASU. Ser.: Stroitel'naya informatika. 2014. Vyp. 12(36). St. 3. URL: http://vestnik.vgasu.ru/attachments/3SanzhapovRyaskov-2014_12(36).pdf (data obrashcheniya 6.03.2018)
4.
Grévisse C., Botev J., Rothkugel S. An Extensible and Lightweight Modular Ontology for Programming Education. Advances in Computing. Materials of the Colombian Conference on Computing. Cali, Colombia, September 19-22, 2017. no. 735. pp. 358-371.
5.
Lavrishcheva E. M. Sistemnaya podderzhka resheniya biznes-zadach v global'noi informatsionnoi seti // Lavrishcheva E. M., Karpov L. E., Tomilin A. N. // Materialy XVII Vserossiiskoi nauchnoi konferentsii Nauchnyi servis v seti Internet. Novorossiisk, 2015. S. 193-218.
6.
Almeida J. et al. An Ontology and a REST API for Sequence Based Microbial Typing Data. Bioinformatics for Personalized Medicine, Berlin, 2012. no. 6620. pp. 21-28.
7.
Ed-Douibi, H., Izquierdo, J. L. C., Gómez, A., Tisi, M., & Cabot, J. EMF-REST: generation of restful apis from models. In Proceedings of the 31st Annual ACM Symposium on Applied Computing 2016. pp. 1446-1453.
8.
Kalinichenko G.A. Sravnenie tekhnologii GraphQL i REST API v razrabotke sovremennykh klient-servernykh prilozhenii // Kalinichenko G.A., Skorokhod S.V. // Tekhnicheskie nauki: problemy i resheniya: sb. st. po materialam III-IV Mezhdunarodnoi nauchno-prakticheskoi konferentsii «Tekhnicheskie nauki: problemy i resheniya». № 3-4(3), Moskva, 2017. S. 47-52.
9.
Codescu M., Mossakowski T., Kutz O. A categorical approach to networks of aligned ontologies. Journal on Data Semantics. no. 6(4). 2017. pp. 155-197.
10.
Burita L. Ontology Development as a Software Engineering Procedure. International Conference on Digital Information and Communication Technology and Its Applications. Berlin, 2011. no. 167. pp. 1-8.