CC BY-NC
9Обеспечение слабой связности экспертной системы и онтологической базы знаний путём добавления обслуживающего слоя
Рясков Андрей Сергеевич
аспирант, кафедра Математика и информационные технологии, Волгоградский государственный
технический университет, Инстшуг архитектуры и строительства
400074, Россия, Волгоградская область, г. Волгоград, уп. А<адемическая, 1, ауд. В-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
За последнее десятилетие увеличилась роль экспертных систем (ЭС) и баз знаний (БЗ) в промышленных процессах -Ш. В дополнение к стандартным источникам наполнения баз знаний фактами — экспертов, в дело входят и другие — например, в области экологического мониторинга — это автономные экологические посты по всей России, с которых поступают данные о замерах контролируемых показателей. Эти данные обрабатываются в автоматизированном режиме и пополняют БЗ. Для эффективного наполнения БЗ особенно важно правильно структурировать входящую информацию. Одной из форм структурирования информации являются БЗ на основе онтологии (онтологической модели). Рассмотрим подробнее экспертные системы на основе онтологических БЗ. На рисунке 1 показана общая архитектура экспертной системы.
Рис. 1. Общая архитектура экспертной системы
Эксперт взаимодействует с БЗ, наполняя её и корректируя. БЗ может быть представлена в различных форматах — логика первого порядка, продукционные правила, в виде правил на основе дизъюнктов Хорна, дескрипционные логики. Именно дескрипционные логики получили широкое распространение в инженерии знаний в виде хранения знаний в онтологических БЗ. Основным форматом физического представления онтологии на сегодняшний момент является формат OWL (сокр. англ. Web Ontology Language — язык сетевых онтологий). Данный формат рекомендован Комитетом Всемирной паутины (W3C) для использования в онтологических БЗ, имеет широкую поддержку со стороны программных инструментов, в наличии имеется открытая и полная документация.
Блок логического вывода отвечает за анализ знаний и вывод новых знаний на основе правил вывода. Для вывода новых знаний используются специальные программные модули — машины вывода (англ. Reasoners).
Блок объяснения — блок, осуществляющий построение цепочки логически связанных
фактов из БЗ для объяснения полученного ответа пользователю.
Блок общения обеспечивает взаимодействие логического модуля ЭС с пользователем и представляет информацию на понятном пользователю языке.
Эксперт — лицо, привлекаемое для наполнения БЗ. ЭС позволяет снизить нагрузку на эксперта за счёт взятия на себя части обязательств по предоставлению знаний польз ов а те ля м.
Пользователь — лицо, которое желает получить поддержку в принятии решения в некоторой предметной области.
Рассмотрим подробнее участок соединения ЭС и БЗ.
Типовая схема взаимодействия ЭС (логического модуля ЭС) с онтологической БЗ формата OWL показана на рисунке 2. Здесь используется промежуточное программное обеспечение (англ. middleware) на основе программного интерфейса приложения (сокр. англ. API) OWL API ^
[ ЭС у.->fn°WL API -Онтология ]
Рис. 2. Взаимодействие логического блока ЭС с онтологической БЗ
Рассмотрим преимущества такой схемы соединения. Основное преимущество введения посреднического программного обеспечения состоит в том, что экспертная система не должна напрямую считывать онтологические сущности. OWL API выполняет всю работу по выборке, сортировке, фильтрации, выводу новых знаний.
Другим преимуществом является то, что OWL API практически не зависит от выбранного языка программирования — на практике программист может использовать одну из множества OWL-обёрток (англ. OWL API-wrappers) для доступа к OWL API.
Однако, существуют и недостатки. В частности, главный недостаток такой связки — плотная интеграция ЭС и БЗ. Если в будущем понадобится использовать другую ЭС с заполненной БЗ, либо подключить другую БЗ к существующей ЭС, возникают проблемы интеграции — необходимо переписать слой стыковки. Это влечёт за собой дополнительные расходы. Как частный случай, если планируется переход от OWL к KIF-онтологиям, OWL API больше не будет работать корректно, нужно будет переписывать модуль взаимодействия с БЗ ^^
В ходе научной работы, описываемой в настоящей статье, было проведено исследование, направленное на обеспечение слабой связности ЭС и БЗ на основе онтологических моделей.
Цель исследования — предложить метод и прикладные технологии, которые позволят уменьшить время адаптации конкретных БЗ к новым экспертным системам, либо наоборот — адаптации экспертных систем для различных БЗ.
Актуальность повышения интеграционной способности онтологической БЗ обусловлена тем, что в последнее время появляется всё больше экспертных систем на основе
подобных БЗ, авторы которых разрабатывают собственных слой взаимодействия с
онтологией J41. Этот подход имеет такой недостаток как необходимость написания нового слоя взаимодействия каждый раз при изменении формата общения БЗ и ЭС.
В качестве посредника между ЭС и БЗ предлагается использовать обслуживающий (серверный, от англ. Server — обслуживающий) слой. Этот дополнительный слой свяжет клиент (ЭС) и сервер (БЗ). Клиент-серверная архитектура уже успешно работает в других областях, где требуется обеспечить слабую связанность компонентов информационной
системы J21.
Новизна предлагаемого подхода заключается в том, что производится унификация взаимодействия экспертных систем с онтологическими базами знаний путём использования метода, который ранее не применялся в подобной области. Метрикой эффективности подхода примем количество времени, которое удалось сэкономить при отсутствии необходимости переписывания блока логического модуля под взаимодействие с новым типом (форматом) БЗ.
В ходе рассмотрения вариантов архитектурных стилей серверного слоя были изучены следующие:
- SOAP-слой
- REST-слой
- GraphQL-слой
SOAP (сокр. англ. от Simple Object Access Protocol — простой протокол доступа к объектам) является наиболее распространённым методом взаимодействия с сервером,
доступно множество инструментов и библиотек для работы по SOAP-^51. Недостатками SOAP являются избыточность информации для обмена, в основном из-за использования языка разметки XML, а также снижение скорости обработки за счёт увеличения объёма передаваемых данных.
Пример ответа сервера на запрос в стиле SOAP:
< soap:Envelope > <soap:Body>
< getPlantDeta ilsResponse >
< 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-^, обладает меньшей избыточностью информации вследствие использования языка разметки JSON. Ответы сервера зависят только от входных параметров (англ. stateless — без состояния). Недостатком REST можно считать необходимость описывать все возможные методы работы с данными на этапе программирования слоя абстракции. Также стоит отметить, что после того, как некоторые операции на онтологии станут бессмысленными, например, вследствие удаления части знаний из БЗ, в REST-слое всё равно останутся методы для работы с ними, в то время, если программист серверного части (БЗ) захочет изменить интерфейс обращения к знаниям (например, изменив сигнатуру некоторых методов), то это повлечёт за собой отказ некоторой части функциональности, которую реализуют ЭС, подключённые к через данный слой к БЗ. Стоит также заметить, что REST не совсем подходит для работы с большими массивами информации, из-за того, что при желании получить некоторый атрибут объекта из списка объектов БЗ, происходит обязательная загрузка полного объекта со всеми его атрибутами (свойствами), и только потом
отделяются нужные пользователю свойства ^^
Пример ответа сервера на запрос по REST: {
id: 325626,
plantName: «ООО Завод специального оборудования»,
description: «Выпуск высокоточного оборудования, солнечных панелей.»,
wastes: {
solidwastes: {
waste: {
ID: '87645-1364', Name: 'Бумага', DangerClass: 4,
AmountT: 5,
IsRecyclable: true }
} } }
GraphQL решает проблему SOAP, уменьшая избыточность поступающих данных, а также проблему REST — позволяя уже на этапе запроса к серверу определять необходимые
для выборки атрибуты и получать от сервера только их вместо целого объекта ^^ GraphQL является современной технологией с достаточной документацией и обеспеченностью программными модулями для реализации обмена данными по этому протоколу.
Архитектура сопрягающего модуля после внедрения серверного слоя представлена на рисунке 3.
Рис. 3. Архитектура системы взаимодействия ЭС-БЗ после внедрения серверного слоя
В новой версии архитектуры показана работа с OWL, KIF и Prolog-базами знаний. Предполагается, что в один момент времени будет использоваться лишь одна из них, хотя совместное использование не исключается. Несколько типов БЗ приведено для демонстрации независимости ЭС от типа БЗ при внедрении данного решения.
Блок онтологической абстракции является связующим звеном уровня API и GraphQL сервера. При передаче данных из БЗ, он формализует их на более высоком уровне и передаёт на сервер GraphQL. При передаче данных в БЗ, он преобразовывает формализованные данные на уровень ниже, в сущности, понятные конкретному онтологическому модулю (например, KIF
Описанный подход был применён на практике в виде разработанного серверного слоя для экспертной системы экологической нагрузки г. Волгограда
Эффективность внедрения серверного слоя измеряется в объёме работы, которую не придётся совершать при смене БЗ или ЭС — написание программного слоя,
обеспечивающего интероперабельность различных версий и типов ЭС и БЗ. Написание слоя взаимодействия логического модуля и БЗ может занимать около 160 часов с
онтологической базой знаний, насчитывающей не более 1000 концептов ИШ. 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. 358371.
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.
10.25136/2306-4196.2018.2.25804
Kw6epHeTMKa ii nporpaMMiipoBaHiue, 2018 -
2
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.
