Translate this page:
Please select your language to translate the article


You can just close the window to don't translate
Library
Your profile

Back to contents

Cybernetics and programming
Reference:

Ensuring Weak Connectivity of the Expert System and Ontological Knowledge Base by Adding the Service Layer

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

DOI:

10.25136/2644-5522.2018.2.25804

Received:

22-03-2018


Published:

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:

ontology, expert system, knowledge base, weak connectivity architecture, client-server architecture, GraphQL, REST API, SOAP, 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 часов — это один человеко-месяц, который будет экономиться при внедрении описанного архитектурного подхода.

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

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

References
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.