Scientific journal
Fundamental research
ISSN 1812-7339
"Перечень" ВАК
ИФ РИНЦ = 1,674

IMPLEMENTATION OF EVENT-BASED KNOWLEDGE CONTROL IN MODELS REPRESENTED BY OBJECT-ORIENTED SEMANTIC HYPERGRAPH

Pochinskiy I.A. 1 Zinkin S.A. 1
1 Federal state budgetary educational institution of Higher Education Penza State University
1230 KB
In the article there is provided formalization example of the serial situation that consists of ordering new service by the client from his ISP. To decomposition that situation event-based conception described earlier is used. Every event connects with one or more production rules that are added to the ready productions forefront when the event occurs. Applying of logical transformation rules activators extension is proposed as the production rule application condition. It provides the possibility of running a production rule right after ending of some event or another production rule. Moreover new concepts of semantically conjunctive and semantically disjunctive lists are introduced. This lists could be used as values of any semantic hypergraph class object property. Semantically disjunctive list is a set, in which one or more elements could be interpreted as a property value. Semantically conjunctive list is a set, in which every element is value of the property.
procedural knowledge
semantic hypergraph
production rules
events
situations
intellectual knowledge management systems (IKMS)
ontology
event-based knowledge control
1. Zaharov V.N., Popov E.V., Pospelov D.A., Horoshevkiy V.F. Iskusstvenny intellect [Artificial Intelligence], Moscow, Radio and connection, 1990.
2. Pochinskiy I.A. Sbornik statej 11 mezhdunarodnoj nauchno-tehnicheskoj konferencii «Problemy informatiki v obrazovanii, upravlenii, ekonomiki i tehnike», Penza, 2011, pp. 74–78.
3. Pochinskiy I.A. Sbornik statej 16 mezhdunarodnoj nauchno-metodicheskoy konferencii (Works of 16th Int. Scientific Technical Conference «Informatics problems in education, management, economic and technique»), Penza, 2012, pp. 443–445.
4. Pochinskiy I.A. Trudy Vserossijskogo konkursa nauchno-issledovatel’skih rabot studentov i aspirantov v oblasti tehnnicheskih nauk: materialy rabot pobeditelej i laureatov konkursa (Proc. All-Russian competition of the science-research works of students and graduates in the technical science area: winners’ and laureates’ works). St-Petersburg, 2012, pp. 139–141.
5. Pochinskiy I.A., Zinkin S.A. Fundamental’nye issledovaniya – Fundamental researches, 2013, no.6 (part 4), pp. 863–866.
6. Pochinskiy I.A. Trudy 5 mezhdunarodnoj nauchno-prakticheskoy konferencii «Molodezh’. Nauka. Innovacii». (Proc. of the 5th Int. Scince and Practic Conference «Youth. Science. Innovations»), Penza, 2012, pp. 373–377.
7. Zadeh, L. Commonsense knowledge representation based on fuzzy logic // Computer. 1983. Vol. 16. рр. 256–281.

В ряде предыдущих работ [2, 3, 6] был исследован семантический гиперграф как формализм представления декларативных знаний, а также аргументирована необходимость представления процедурных знаний в интеллектуальных системах управления знаниями. В работе [5] был предложен событийный подход к представлению процедурных знаний и управлению онтологиями. В данной работе приводится пример реализации событийного подхода к управлению системой продукционных правил для формализации процедурных знаний моделируемой системы.

В качестве значений свойств события могут быть использованы ссылки на один или несколько классов или их экземпляров. В таком случае семантическая связь этого свойства будет инцидента каждой вершине (или одной из вершин), указанной в его (свойства) значении. Графически обозначать такую семантической дугу предлагается с помощью контура вокруг всех вершин, указанных в значении свойства, к которому направлена стрелка от вершины-события (свойство которого и рассматривается), причем в месте соприкосновения контура и стрелки изображать окружность с вписанным в нее символом конъюнкции (дизъюнкции). В качестве символьной записи предлагается использовать следующую конструкцию: {&: v1, v2, …, vk}, где v1, v2, …, vk – множество вершин, записанных в значении свойства. Такие семантические дуги предлагается называть событийно-конъюнктивными (событийно-дизъюнктивными), а множества – событийно-конъюнктивными (событийно-дизъюнктивными) списками.

Событийно-конъюнктивные и событийно-дизъюнктивные дуги, являясь средствами представления недоопределенной, неполной, неточной информации, повышают выразительные возможности ИСУЗ [7].

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

Клиент заказывает у провайдера услугу предоставления доступа к SIP-телефонии, но на его лицевом счету недостаточно средств для оплаты этой услуги, поэтому доступ к ней блокируется. После оплаты клиентом стоимости услуги блокировка снимается, и клиент совершает исходящий звонок.

Для описания формализации последовательной событийной ситуации будет использоваться модель декларативных знаний, полученная в [4].

При допущении, что локальная сеть клиента подключена только к одному провайдеру, ее аппаратное обеспечение поддерживает услугу SIP-телефонии, а биллинговая система провайдера предоставляет возможность только авансового метода расчета, обобщенный набор событий, возникающих в системе, представлен ниже.

1. Заказ клиентом у провайдера услуги SIP-телефонии:

Объект: экземпляр класса service:SIP, семантически связанный с экземпляром класса isp, который в свою очередь семантически связан с экземпляром класса client, ассоциированным с клиентом Ивановым.

Субъект: экземпляр класса client, ассоциированный с клиентом Ивановым.

Правила:

a) семантическое связывание объекта и субъекта семантической дугой has_service.

2. Изменение прав доступа для клиента на оборудовании провайдера:

Объект: экземпляр класса interface, ассоциированный с портом доступа на оборудовании провайдера, к которому подключен клиент Иванов.

Субъект: объект класса isp, ассоциированный с провайдером, услугами которого пользуется клиент Иванов.

Правила:

a) изменение свойства destination объекта на trunk;

b) добавление к значению свойства service объекта ссылки на экземпляр класса service:SIP (объект события 1).

3. Конфигурирование абонентского оборудования:

Объект: 2 экземпляра класса interface, ассоциированных с интерфейсами пограничного устройства локальной сети клиента Иванова, подключенных к порту доступа оборудования провайдера и к SIP-телефону клиента Иванова.

Субъект: экземпляр класса client, ассоциированный с клиентом Ивановым.

Правила:

a) изменение свойства destination объекта 1 (ассоциированного с интерфейсом пограничного устройства локальной сети клиента Иванова, подключенным к оборудованию провайдера) на trunk;

b) изменение свойства state объекта 2 (ассоциированного с интерфейсом пограничного устройства локальной сети клиента Иванова, подключенным к SIP-телефону) на active;

c) изменение свойства destination объекта 2 на clientSIP.

4. Списание провайдером оплаты за услугу с лицевого счета клиента:

Объект: свойство personal_account экземпляра класса client, ассоциированного с клиентом Ивановым.

Субъект: объект класса isp, ассоциированный с провайдером, услугами которого пользуется клиент Иванов.

Правила:

a) изменение объекта в соответствии со значением свойства cost экземпляра класса service:SIP, ассоциированного с услугой, заказанной клиентом Ивановым.

4. Блокирование доступа клиента к сети передачи данных:

Объект: экземпляр класса interface, ассоциированный с портом доступа на оборудовании провайдера, к которому подключен клиент Иванов.

Субъект: объект класса isp, ассоциированный с провайдером, услугами которого пользуется клиент Иванов.

Правила:

a) если значение свойства personal_account экземпляра класса client, ассоциированного с клиентом Ивановым, меньше 0, то изменение свойства state объекта на blocked.

6. Зачисление денег на лицевой счет клиента:

Объект: свойство personal_account экземпляра класса client, ассоциированного с клиентом Ивановым.

Субъект: экземпляр класса client, ассоциированный с клиентом Ивановым.

Правила:

a) изменение объекта в соответствии с текущим и целевым его значениями.

7. Предоставление доступа клиента к сети передачи данных:

Объект: экземпляр класса interface, ассоциированный с портом доступа на оборудовании провайдера, к которому подключен клиент Иванов.

Субъект: объект класса isp, ассоциированный с провайдером, услугами которого пользуется клиент Иванов.

Правила:

a) изменение свойства state объекта на active.

8. Исходящий SIP-звонок клиента:

Объект: экземпляр класса service:SIP, семантически связанный с экземпляром класса isp, который в свою очередь семантически связан с экземпляром класса client, ассоциированным с клиентом Ивановым.

Субъект: экземпляр класса client, ассоциированный с клиентом Ивановым.

Правила:

a) изменение свойства personal_account субъекта в соответствии со значением свойства cost_call объекта.

Для события 1 нет необходимости указывать в качестве одного из дополнительных параметров провайдера, у которого заказывается услуга, т.к. заранее было оговорено, что клиент пользуется услугами только одного провайдера, в противном случае необходимо было бы предусмотреть процедуру определения провайдера, услугу у которого заказал клиент.

Для события 3 объектом являются 2 вершины-экземпляра класса interface. Формально объект события 3 представляется как семантически-конъюнктивный список.

Формально создание событий в терминах семантических гиперграфов выглядит следующим образом. Сначала необходимо создать сам класс event, экземпляры которого и будут являться событиями, описанными выше.

Eqn32.wmf

Ниже приведена формальная запись создания экземпляра класса event для первого события рассматриваемой ситуации. В качестве значения свойства evType используется название ситуации, в которую входит событие (в случае если событие входит в несколько ситуаций, значением данного свойства будет являться событийно-конъюнктивный список, элементами которого будут являться названия каждой из ситуаций).

Eqn33.wmf

По аналогии с вышеприведенным вариантом создаются остальные события.

После создания всех экземпляров класса event для задания порядка возникновения событий в модели необходимо произвести каузальное связывание созданных экземпляров.

Первое событие является начальным в рассматриваемой ситуации, причиной его возникновения могут являться события других ситуаций. Поскольку в данной работе они не рассматриваются, будем использовать это событие как стартовое. Для возникновения второго и третьего событий необходимо возникновение первого. Для возникновения четвертого события необходимо возникновение второго события. Для возникновения пятого события необходимо отрицательное значение объекта четвертого события. Представление такой связи невозможно с помощью каузальных дуг (реализовать это можно в ядре правил продукций или с помощью алгоритмических решений при проектировании ИСУЗ), поэтому будем считать, что для возникновения пятого события необходимо возникновение четвертого, а обработку логического условия возложим на правило продукции, связанное с пятым событием. Для возникновения шестого события необходимо возникновение пятого. По аналогии с причиной возникновения пятого события для возникновения седьмого необходимо возникновение шестого события. Для возникновения восьмого события необходимо возникновение второго, третьего и седьмого событий. Формально это записывается следующим образом:

Eqn34.wmf

Ниже формально записан спектр продукций с правилами модификации исходной модели. В качестве сферы применения продукций выступает название события, при возникновении которого данная продукция будет отнесена к фронту готовых продукций. В качестве антецедент продукций используются условия существования обрабатываемых продукцией вершин. Кроме того, в продукциях использованы названия переменных objecti и subjecti с индексами, которые обозначают объект и субъект i-го события соответственно.

В качестве условий применимости продукций использовано расширение активаторов логико-трансформационных правил [1] – ON_FINISHED(), предоставляющее возможность запуска продукционного правила по завершении события или продукции, указанных в скобках этого активатора.

В составе антецедент ядер продукций используется операция exist(), принимающая истинное значение в случае, если вершина, указанная в скобках, существует в модели, и ложное в противном случае.

Eqn35.wmf (i1)

Eqn36.wmf (i2)

Eqn37.wmf (i3)

Eqn38.wmf (i4)

Eqn39.wmf (i5)

Eqn40.wmf (i6)

Eqn41.wmf (i7)

Eqn42.wmf (i8)

Eqn43.wmf (i9)

Eqn44.wmf (i10)

Eqn45.wmf (i11)

Вывод

В данной работе приведен пример проектирования последовательной фактической системы, описанной онтологией сети провайдера, знания в которой представлены с помощью объектно-ориентированного семантического гиперграфа. Практически доказана относительная несложность применения правил продукционного вывода для управления динамикой семантики модели системы.

Рецензенты:

Егоров С.И., д.т.н., доцент, профессор кафедры вычислительной техники, ФГБОУ «Юго-Западный государственный университет», г. Курск;

Ромм Я.Е., д.т.н., профессор, заведующий кафедрой информатики, ФГБОУ ВПО «ТГПИ имени А.П. Чехова», г. Таганрог.

Работа поступила в редакцию 19.07.2013.