Онтологии для разработки и генерации адаптивных пользовательских интерфейсов редакторов баз знаний

Интеллектуальные системы с базами знаний (БЗ): экспертные системы, системы поддержки принятия решений, компьютерные тренажёры и др., широко используются во многих предметных областях (ПрО): медицина, экономика, химия и биология, военное дело, инженерное дело, экология, производство, управление процессами, юриспруденция и др. Именно БЗ является «бутылочным горлышком» таких систем [1-4]. Основная сложность связана с их формированием и сопровождением экспертами ПрО. Для упрощения создания и сопровождения БЗ активно применяется онтологический подход, который в настоящее время является стандартом для их создания (см. также [5, 6]). Вместе с тем, наличие онтологии, по которой формируется БЗ, недостаточно для удобной работы экспертов ПрО. Немаловажное значение имеют также онтологическая модель знаний и пользовательский интерфейс, который является ключевым фактором при принятии решения об использовании программного средства.

Для работы с онтологиями и БЗ применяются различные онтологические редакторы знаний ( IWE, Protege, OntoEdit, GrOWL, Graphl, RDFGravity, WebVOWL, Ontolingua и др.). Пользовательские интерфейсы этих редакторов реализуют фиксированный сценарий без возможности настройки и адаптации к потребностям пользователей (некоторые редакторы имеют режимы выбора просмотра информации, но не позволяют редактирование). Объёмы БЗ для интеллектуальных систем включают тысячи и десятки тысяч понятий на разных уровнях иерархии, что является дополнительным фактором, усложняющим использование таких редакторов экспертами ПрО. Актуальной задачей является разработка методов создания редакторов БЗ с адаптивным пользовательским интерфейсом.

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

Предложены различные схемы и алгоритмы разделения интерфейса по уровням абстракции и генерации адаптированного интерфейса на основе онтологий и других элементов [3, 912]. В данных работах можно отметить существенный прогресс в адаптивных технологиях интерфейса: рассмотрены различные концепции адаптивных систем для различных устройств и для генерации интерфейса, в том числе в зависимости от меняющихся условий внешней среды. Однако по-прежнему отсутствует связь адаптации интерфейса непосредственно с ПрО и пользователем.

В работах [13, 14] предложены достаточно полноценные концепции адаптивного пользовательского WIMP 1 -интерфейса, в том числе так называемые «пластичные» пользовательские интерфейсы. Данные работы посвящены узким задачам построения интерфейса и не решают проблему адаптивного интерфейса на основе онтологии произвольной ПрО.

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

Целью данной работы является детальное описание авторского подхода к разработке адаптивных WIMP -интерфейсов на основе онтологии ПрО и онтологической БЗ о проектировании интерфейсов.

1    Концепция разработки WIMP-интерфейсов для редакторов баз знаний

В работах [15, 16] описан подход к автоматической генерации редакторов знаний, основная идея которого заключается в следующем: на основе знаний о проектировании интерфейса, онтологии ПрО и модели пользователя автоматически генерируется пользовательский интерфейс редактора знаний (см. рисунок 1).

• 1 WIMP - «Windows, Icons, Menus, Pointers» — окна, значки, меню, указатели.

Рисунок 1 - Формирование редактора с адаптивным WIMP -интерфейсом

Реализация подхода включает следующие работы.

• 1)    Введение абстрактных элементов интерфейса. Они определяют интерфейсные задачи без явного определения их визуального и функционального представления. Каждый абстрактный элемент интерфейса имеет несколько вариантов представления - адаптаций абстрактных элементов . Выбор конкретной адаптации определяется в зависимости от выполнения ряда условий (операционной системы, устройства, структуры информации, типа пользователя, его предпочтений, среды использования и др.). Абстрактные элементы интерфейса используются для описания знаний о проектировании интерфейса: для каждой интерфейсной задачи (абстрактного элемента интерфейса) и множества условий описываются возможные способы их отображения в WIMP -интерфейсе.

• 2)    Формирование базы WIMP-элементов на основе онтологии WIMP-элементов интерфейса. Каждая адаптация абстрактного элемента имеет конкретное визуальное и функциональное представление в виде готовых повторно используемых WIMP -элементов, таких как списки, кнопки, меню и т.д.

• 3)    Формирование БЗ о проектировании WIMP-интерфейса. БЗ содержит правила его формирования в зависимости от структуры онтологии ПрО, характеристик пользователя, требований удобства использования.

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

• 5)    Разработка генератора интерфейса , который по онтологии ПрО, БЗ о проектировании интерфейса и модели интерфейса формирует пользовательский интерфейс редактора знаний, ориентированного на конкретного пользователя.

Для реализации предложенного подхода авторами разработаны следующие онтологии:

• ■   онтология БЗ о проектировании WIMP - интерфейса;

• ■   онтология WIMP -элементов;

• ■   онтология модели интерфейса.

Для формального представления онтологий в работе [17] предложен метаязык, который в течение ряда лет используется на платформе IACPaaS. Онтология представляется иерархическим графом, вершинами графа являются термины онтологии, а дуги определяют следующие типы отношений для описания правил порождения знаний на основе онтологии:

• ■   ~ copy — «копия», термин онтологии переносится без изменений в БЗ;

• ■   ~ one — «в точности один», можно породить только один элемент в БЗ, соответствующий

термину онтологии;

• ■   ~ set — «непустое множество», возможно порождение одного или нескольких отличаю

щихся по имени элементов по соответствующему термину онтологии;

• ■   ~ seq — «непустая последовательность», порождение элементов в БЗ с автоматически

сгенерированной нумерацией (порядком);

• ■   ~ copymm — «возможное отсутствие», аналог «~ copy », но порождение не является обяза

тельным для полноты базы;

• ■   ~ onemm — «ноль или один», аналог «~ one », но порождение не является обязательным

для полноты базы;

• ■   ~ setmm — «возможно пустое множество», аналог «~ set », но порождение даже одного

элемента не является обязательным для полноты базы;

• ■   ~ seqmm — «возможно пустая последовательность», аналог «~ seq », но порождение даже

одного элемента последовательности не является обязательным для полноты базы;

• ■   ~ proxy — «прокси», служит для организации порождаемых элементов в условные груп

пы с «невидимым» контейнером.

2    Онтология знаний о проектировании интерфейса

Онтология знаний о проектировании интерфейса определяет соответствия между абстрактными интерфейсными элементами и их возможными представлениями в интерфейсе в зависимости от ряда условий.

Абстрактными интерфейсными элементами (задачами) являются:

• ■    элемент ввода - элемент, предоставляющий возможность ввести данные через подходящий интерфейсный компонент;

• ■    элемент вывода - элемент, обеспечивающий возможность вывести данные через подходящий интерфейсный компонент;

• ■    выбор - элемент для выбора элементов из множества, которое задаётся либо явно, через указание всех элементов, либо генерируется автоматически;

• ■    контейнер - интерфейсный элемент для объединения нескольких элементов интерфейса в рамках одной задачи.

Каждая абстрактная задача имеет свои подзадачи. Например, задача выбора имеет подзадачи: выбор одного варианта из множества, выбор подмножества вариантов из множества.

Можно рассмотреть онтологию абстрактных интерфейсных элементов:

~copy Абстрактные интерфейсные элементы {

~copy Выбор {<Уникальные подзадачи>}

~copy Ввод {<Уникальные подзадачи>}

~copy Вывод {<Уникальные подзадачи>}

~copy Контейнер {<Уникальные подзадачи>}

}

<Уникальные подзадачи>::{ Уникальная подзадача ; }

~copy< Уникальная подзадача^}

~copy<Реализация по умолчанию для задачи >

~copy Элементы интерфейса {

~set Элемент интерфейса {

~copy<Данные, влияющие на выбор элемента интерфейса>

~copy<Реализация элемента интерфейса>

}

}

}

Элементы интерфейса - это множество вариантов реализации указанной подзадачи -элементов интерфейсов. Выбор того или иного элемента зависит от условий, которые прописаны внутри каждого элемента.

• ²    Каждая из подзадач имеет идентичную структуру.

Реализация по умолчанию для задачи - это базовое преставление абстрактного элемента интерфейса на основе заданного по умолчанию WIMP -элемента с конкретными параметрами.

Данные, влияющие на выбор элемента интерфейса, содержат описание параметров входных данных (элементов знаний), согласно которым выбирается указанный элемент интерфейса для реализации выбранной подзадачи.

~copy Данные, влияющие на выбор элемента интерфейса {

~copymm Онтологические конструкции { … }

~copymm Особенности данных {

~set Особенность [string]

}

~onemm Количество потомков [integer]

~onemm Минимальное количество потомков [integer]

~onemm Максимальное количество потомков [integer]

}

Онтологические конструкции - описание, содержащее множество условий для определения элемента интерфейса для данного элемента онтологии.

~copymm Онтологические конструкции {

~copymm Конструкция {

~copy Элементы онтологии {

~copymm Список или альтернатива {СПИСОК | АЛЬТЕРНАТИВА}

~copy Тип элемента { нетерминал | терминал-сорт | терминал-значение}

~copymm Тип значения {Строковое | Целое | Вещественное | Логическое | Дата и время | Бинарные значения}

~copy Спецификатор (тип отношения) { copy| copymm | one | onemm | list | listmm | set | setmm | seq | seqmm | proxy} }

~copymm Уровень размещения (глубина вложенности) {1 | >1}

~copymmЭлементы онтологии, расположенные на одном уровне {

~set->Элементы онтологии { ... }

~copymm Элементы онтологии отсутствуют [string]

~seqmm Логическая операция И | ИЛИ | НЕ}

}

~copymm Содержимое {

~set->Элемент { ... }

~seqmm Логическая операция {И | ИЛИ | НЕ}

}

~copymm Количество потомков {

~onemm Фиксированное количество потомков

• ~    onemm Минимальное количество потомков

• ~    onemm Максимальное количество потомков

}

}

}

Каждая конструкция содержит: элементы онтологии; уровень размещения; элементы онтологии, расположенные на одном уровне; содержимое; количество потомков.

Элементы онтологии - раздел, который содержит множество элементов онтологии (представленных в виде перечня свойств), которые необходимо преобразовать в элемент интерфейса.

Уровень размещения - указание, на каком уровне в онтологии размещён элемент (по иерархии). Было выявлено, что есть разница в реализации для некоторых элементов, которые могут находиться на первом уровне размещения в онтологии.

Элементы онтологии, расположенные на одном уровне, - список из элементов онтологии, которые могут находиться на одном иерархическом уровне с текущим элементом онтологии.

Содержимое - дочерние элементы для текущего элемента онтологии. Может содержать логическую операцию между элементами.

Количество потомков – описывает границы возможного количества потомков.

Конструкции и их элементы описаны в онтологии, представленной на рисунке 2.

.▼ Онтологические конструкции * {СПИСОК} v *• Конструкция {СПИСОК}

• ▼    н Элементы онтологии * {СПИСОК}

| I | #► Список или альтернатива * ([=] 'copymm') (ref-new) i !    ► Тип элемента ( ='copy') (ref-new)

И I ► Тип значения * ([=] 'copymm') (ref-new) t> Спецификатор (= 'copy') (ref-new) описать элемент списка:

г Уровень размещения (глубина вложенности) * {АЛЬТЕРНАТИВА}

S1 (тип: строковое) (= 'copy') (ref-new)

iO >1 (тип: строковое) (= 'copy') (ref-new) описать вариант альтернативы г Элементы онтологии расположенные на одном уровне * {СПИСОК} *.....

• ►    >• Элементы онтологии * ( + 'set') (new) :► >• Логическая операция * ([^л] 'seqmm') (new) О Элементы онтологии отсутствуют (тип: строковое) * ((=] 'copymm') (ref-new) описать элемент списка

г Содержимое * {СПИСОК}

• ►    >- Элементы онтологии * (+ 'set') (new) ► >• Логическая операция * ([^л] 'seqmm') (new) i i описать элемент списка            © ©

| i ▼ Количество потомков {СПИСОК} о Фиксированное количество потомков (сорт: целое) ([!] 'onemm') (all)

: j Р Минимальное количество потомков (сорт: целое) ([!] 'onemm') (all) j О Максимальное количество потомков (сорт: целое) ([!] 'onemm') (all) | j : описать элемент списка:

Рисунок 2 – Скриншот раздела «онтологические конструкции» на платформе IACPaaS

Особенности данных (знаний) – элемент онтологии, содержащий условия, которые определяют интерфейсный элемент для реализации в зависимости от структуры входных данных (знаний).

Количество потомков определяет условие по числу дочерних элементов. Например, если у элемента «список-выбор» меньше 5 дочерних элементов, то его можно представить в виде группы радиокнопок, если же больше 5, то лучше использовать выпадающий список (см. рисунок 3).

Реализации элемента интерфейса (см. рисунок 4) состоят из множества Реализаций . Каждая Реализация состоит из двух частей: Характеристики устройств (для которых подходит данная реализация) и Дизайн – непосредственное определение интерфейсного отображения элемента. Дизайн определяется с помощью элементов CommonElements либо через уникальный набор CSS -свойств ³ . CommonElements – один из WIMP -элементов БЗ для применения в данной реализации. CSS – описание стилей WIMP -элементов: {ширина (элемента), высота, цвет фона, размер текста и др. по аналогии с каскадными таблицами стилей из вебтехнологий [18]}.

Онтология Реализации элемента интерфейса.

~copy Реализации элемента интерфейса {

~set Реализация {

} }

~copy Характеристики устройств { ~setУстройство { … }

}

~copy Дизайн {

~copy->CommonElements { … }

~copy –>CSS{ … }

}

Рисунок 3 – Схема реализации условий абстрактным элементом «Выбор» в редакторе с адаптивным WIMP -интерфейсом

v *• Элемент интерфейса {СПИСОК.

► Данные влияющие на выбор элемента интерфейса ( = 'copy') (ref-new)

Т Реализации элемента интерфейса {СПИСОК}

• ▼    Реализация {СПИСОК}

• ▼    Характеристики устоойс'в {СПИСОК}

• ▼    Устройство {СПИСОК)

О Ширина (сорг: целое) ([!] 'onemm') (all)

О Высота (сорт: целое) ([!] 'onemm') (ali)

► Тип ОС ([_| 'copymm') (r ef-new)

► Тип устройства Q=] 'cooymm') (ref-new)

описать элемент списка:

описать элемент списка.

• ▼    Дизайн (СПИСОК)

► *• CSS ( = 'copy1) (ref-new)

► >• Common Е ements ( = 'copy') (ref-new)

описать элемент списка.

описать элемент списка:

описать элемент списка:

описать элемент списка

Рисунок 4 – Скриншот раздела онтологии «Реализации элемента интерфейса» на платформе IACPaaS

На основе описанной онтологии сформирована БЗ о проектировании интерфейса. Размер базы – 1812 понятий, число отношений – 1864.

На рисунке 5 представлен пример описания абстрактной задачи в БЗ на основе структуры <Выбор одного варианта из множества> в задаче «Выбор»:

~copy Выбор {

~copy Выбор одного варианта из множества {

~copy<Реализация по умолчанию для задачи >

~copy Элементы интерфейса {

~set Элемент интерфейса {

~copy<Данные, влияющие на выбор элемента интерфейса> ~copy<Реализация элемента интерфейса>

}

}

}

}

Т Выбор

• ▼    Выбор одного эариан'а из множества . ? ¹

• ►    Реализация по умолчанию для задачи *

• ▼    Элементы интерфейса *^

• ▼    Гругпа радиокнопок [Элемент интерфейса)

• ▼    Данные влияющие на выбоэ элемента интерфейса

• ▼    Онтологические конструкции"^

• ► »• АЛЬТЕРНАТИВА, нетерминал, copy, copymm. ур. разм. >1 , содерж.

Вещественное I Дата и время I Бинарные значения сору [Конструкция]

f Конструкция ] ф ф

► Особенности данных '^-'

О 2 ' [Минимальное количество потомков (сор-: целое)]

О 5 ' [Максимальное количество потомков (сорт: целое)]

[ Количество потомков (сорт: целое) 1 ф ф ф

• ▼ Реализации элемента интерфейса

• ► По умолчанию [Реализация]

[ Реализация ] ф ф

• ►    Гругпа пеоеключателей [Элемент интерфейса]

• ▼    Раскрывающийся список [Элемент интерфейса]

• ▼    Данные влияющие на выбоэ элемента интерфейса   „ -

• О 5 * [Минимальное количес'во потомков (сор-: целое)]

О 25 ' [Максимальное количество потомков (сорт: целое)]

Т Онтологические конструкции *   ^

• ►    »• АЛЬТЕРНАТИВА, нетерминал, copy, copymm, ур. разм. >1 , содерж.

Вещественное I Дата и время I Бинарные значения сору [Конструкция]

{ Конструкция ] ф ф

{ Особенности данных ]* ф ф

[ Количество потомков (сорт: целое) ]

• ►    Реализации элемента интерфейса

• ►    Поле списка с возможносью выбрат 1 элемент [Элемент ишерфейса]

Рисунок 5 – Скриншот фрагмента БЗ о проектировании интерфейса на платформе IACPaaS

Иллюстрация адаптивной генерации интерфейсного элемента на основе сформированной БЗ абстрактных элементов по представленной выше онтологии показана на рисунке 6 на примере генерации редактора БЗ по онтологии ПрО.

В представленной на рисунке схеме видно, что для абстрактного элемента «Выбор» заданы несколько возможных вариантов элементов интерфейса: «Группа радиокнопок», «Группа переключателей», «Раскрывающийся список» и др. Для каждого из этих интерфейсных элементов выбора заданы онтологические конструкции, для которых данный элемент может подходить. Например, для группы радиокнопок указаны онтологические конструкции: «Альтернатива, нетерминал, copy, copymm,…». Такие же конструкции заданы и для элемента «Раскрывающийся список». Каждый из этих двух вариантов будет зависеть от

«Данных, влияющих на выбор элемента интерфейса». В первом случае заданы параметры количества элементов от 2 до 5, во втором случае от 5 до 25. Справа на схеме видно, что представленная онтология ПрО соответствует данным элементам интерфейса. Пример БЗ 1 по этой онтологии генерирует в результате группу радиокнопок, Пример БЗ 2 - раскрывающийся список в соответствии с количеством элементов.

Генерируемый адаптивный интерфейс

Комплекс лабораторных и инструментальных исследований Лабораторное исследование крови [Исследование набора! Инструментальное исследование сердца [Исследование ni

О Вариант (сорт: строковое) ( + 'set') (ail) описать вариант альтернативы

Комплекс жалоб и объективного обследования

I Боль в грудной клетке [Признак!

I Одышка [Признак]

I Частота пульса на лучевой артерии [Признак]

I Ритм пульса на лучевой артерии [Признак]

► I Наполнение пульса на лучевой артерии [Признак]

► I Систолическое артериальное давление [Признак]

I Диастолическое артериальное давление [Признак]

Боль в грудной клетке

Одышка частота пульса

Ритм пульса наполнение пульса

Систолическое давление

Диастолическое давление

Рисунок 6 - Пример адаптивной генерации интерфейса

База знаний абстрактного элемента "Выбор

Выбор одного варианта из множества

• ► Реализация по умолчанию для задачи

• ▼ Элементы интерфейса *

• ▼    Группа радиокнопок [Элемент интерфейса]

• ▼    Данные влияющие на выбор элемента интерфейса

ТОнтологическиеконструкции"_________________

• ► *- АЛЬТЕРНАТИВА, нетерминал, copy, copy mm. ур. разм

Вещественное I Дата и время I Бинарные значения, сору [Конструкция]

► Особенности данных *

О 2 ' [Минимальное количество потомков (сорт: целое)!

О 5 • [Максимальное количество потомков (сорт: целое);

; Количество потомков (сорт целое)]

V Реализации элемента интерф< ► По умолчанию [Реализация] / Реализация J ф ®

Группа переключателей [Элемент интерфейса)

Раскрывающийся список [Элемент интерфейса] ▼ Данные влияющие на выбор элемента ин терфейса

О 5 • [Минимальное количество потомков (сорт: целс

О 25 * [Максимальное количество потомков (сорт: целое)]

• ▼ Онтологические конструкции *

• ► >- АЛЬТЕРНАТИВА, нетерминал, copy, copy mm, ур. разм, >1 , содерж

Вещественное I Дата и время I Бинарные значения, сору [Конструкция] ¹ [Конструкция]¹ ■

( Особенности ванных Г Ф ®

[Количество потомков (сорт целое)] <•'     :t)

► Реализации элемента интерфейса

Поле списка с возможностью выбрать 1 элемент [Элемент интерфейса]

Онтология ПО

▼ Выбор {АЛЬТЕРНАТИВА}

описать элемент списка:

Пример Базы знаний 1

Пример Базы знаний 2

3 Онтология WIMP-элементов

Онтология WIMP -элементов состоит из двух основных разделов:

• ■    множество WIMP -элементов (независимые интерфейсные единицы, несущие собственную смысловую и функциональную нагрузку: кнопка, поле ввода, список и др.);

• ■    множество стилей CSS (стили определяют оформление внешнего вида интерфейсных элементов, начиная от простых, таких как шрифт, цвет, размер элементов, до составных, содержащих наборы интерфейсных решений).

Онтология WIMP элементов {

~copyCommonElements{…}

~copyCSS {…}

}

Онтология содержит 38 базовых элементов интерфейса <~ copyWIMP -элементы>, среди которых представлены такие элементы как: кнопка ( Button ), чек-боксы ( CheckboxGroup ), радиокнопки ( RadioButtonGroup ), текст ( Text ), текстовое поле ввода ( Input ), комбинированное поле со списком ( Combobox ), кнопка пошаговой прокрутки ( Stepper ) и др. Структурно каждый из этих элементов в онтологии WIMP состоит из некоторого набора уникальных для данного элемента атрибутов и стилей CSS ( options ).

~setmm WIMP-элемент {

~copyoptions

<Набор уникальных свойств>}

Элемент интерфейса Div является базовым универсальным элементом-контейнером с возможностью включения других элементов. Основная особенность его определения заклю- чается в «рекурсивности»: Div - это WIMP -элемент, способный включать как другие элементы, так и элементы того же типа (Div). Этот элемент (также как и другие WIMP -элементы) содержит собственный набор стилей CSS.

~set Div: {

~set ->Div

~set ->CSS

~set ->Text

<^ другие элементы>

}

~setmm Text: {

~copy->options ~onetext

}

Кнопка ( Button ) является сложным элементом и состоит из группы более простых элементов. Кнопка всегда содержит оформление блока CSS , а так же может содержать текст ( Text ) и пиктограмму ( Ico ), располагаемую на кнопке; подсказку ( Hint ), которая выводится на экран при наведении курсора на кнопку. Помимо этого кнопка содержит раздел, отвечающий за состояния ( States ), в которых она может находиться.

~setmm Button: {

~copy->options

~copymm -> Text

~copymm -> Hint

~copymm ->Ico

~copy states { ~set ->options }

}

Текстовое поле ввода ( Input ) содержит текст ( Text ) рядом с полем, описывающий данные, которые необходимо ввести. Возможно присутствие элемента ( Div ), отвечающего за токени-затор ввода, и наличие текста внутри поля ( Text ), подсказывающего возможное вводимое значение.

~setmm Input: {

~copy->options

~copy -> Text

~copymm ->Text

~copymm ->Div

}

WIMP -элементы Combobox и RadioGroup характерны тем, что определяют не один элемент, а несколько. Элементы Combobox и RadioGroup в большей степени определяют форму и поведение группы. Каждый из них содержит ссылку на соответствующий элемент и текст ( Text ), отвечающий за заголовок группы.

~setmmRadioButtonGroup: {

~copy -> Checkbox

~copy -> Text

~copy->options

}

~setmmCheckboxGroup: {

~copy ->Radiobutton

~copy ->Text

~copy->options

}

На платформе IACPaaS разработана онтология WIMP элементов, соответствующая приведённому формальному описанию (см. рисунок 7).

>• Common Elements * {СПИСОК}

ie 0

▼ »• Text‘{СПИСОК}

Otext (сорт: Строковое) *( I 'one') (all) ► >• options (= 'copy') (ref-new)

описать элемент списка' © Ф©®

»• 1прШ*{СПИС0К}

► >• Text * (= 'copy') (ref-new) ► »• Text * (= 'copy') (ref-new) ► >• Div * (= 'copy') (ref-new) ► >• options (= 'copy') (ref-new) описать элемент списка:

▼ Textarea* {СПИСОК}

► >• Input (= 'copy') (ref-new)

> >• options (= 'copy') (ref-new)

описать элемент списка:     Q®Q

• ►    »- Radiobutton * ([*] 'listmm') (ref-new)

• ►    RadioButtonGroup‘([‘] 'listmm') (ref-new)

• ►    >- Checkbox * ([*] 'listmm') (ref-new)

• ►    CheckboxGroup *([*] 'listmm') (ref-new)

Рисунок 7 - Скриншот фрагмента онтологии WIMP элементов

Стили CSS определяются в онтологии по принципу максимальной аналогии и сходства с традиционными стилями CSS , известными в веб-разработке. Стиль CSS определяется парой <  selector, options >:

~copyCSS {

-copyselector {< — >}

-copyoptions {< — >}

}

Селектор ( selector ) так же, как и в традиционных CSS , определяет, для каких именно элементов интерфейса применить заданные правила (свойства) и в онтологии определяется так:

~copy selector: {

-set tag: <*, Base, Text, Button, Div, List, „>

~set class: String

~set id: String

}

Тело ( body ) стиля < -copyoptions> содержит набор свойств, которые будут применяться для соответствующих селектору элементов. Набор свойств стилей определяется по аналогии с традиционными CSS из веб-разработки: ширина, высота, цвет, отступы и т.д.

~copy body: {

~one width

~one height

-one layout: [vertical, horizontal, frame (поверх всех окон), „.]

}

На рисунке 8 представлено описание фрагмента онтология CSS -стилей.

4    Онтология модели интерфейса

Онтология модели интерфейса состоит из двух основных компонентов: {Сохраненные интерфейсы, Информация о пользователе}.

Онтология модели интерфейса {

~copy Сохраненные интерфейсы {…}

~copy Информация о пользователе {…}

}

▼ » CSS {СПИСОК}

► selector ( = 'copy') (ref-new) v

▼ >• options {СПИСОК}

0 background (сорт: строковое) ([!] 'onemm') (all)

.0 background-color (сорт: строковое) (['] 'onemm') (all)

0 background-image (сорт: строковое) ([!] 'onemm') (all)

0 background-repeat (сорт: строковое) ([!] 'onemm') (all)

0 background-size (сорт: строковое) ([!] 'onemm') (all)

0 background-position (сорт: строковое) ([!] 'onemm') (all)

0 border (сорт: строковое) * ([!] 'onemm') (all)

0 border-radius (сорт: строковое) ([!] 'onemm') (all)

0 bottom (сорт: строковое) * ([!] 'onemm') (all)

0 box-shadow (сорт: строковое) * ([!] 'onemm') (all)

0 box-sizing (сорт: строковое) * ([!] 'onemm') (all)

0 color (сорт: строковое) * ([!] 'onemm') (all)

Рисунок 8 - Скриншот фрагмента онтологии CSS -стилей

Элемент онтологии «Сохраненные интерфейсы» определяет структуру для сохранения и отображения интерфейса, специфичного для каждого пользователя. Данная структура позволяет запоминать все выбранные настройки и изменения в интерфейсе, сделанные для конкретного пользователя. Индивидуальный интерфейс пользователя состоит из 5 основных элементов: {Размещение элементов, Внешний вид элементов, Шаблон, Вычисляемая информация о поведении пользователя, Общий CSS }.

Сохраненные интерфейсы {

~set Имя сервиса {

~set Размещение элементов

~set Внешний вид элементов

~copy Шаблон

~copy Вычисляемая информация о поведении пользователя

~copy Общий CSS

}

}

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

Размещение элементов {

~set Поэлементная информация {

~copy Элемент онтологии

~copy Позиционирование элемента интерфейса

}

}

«Шаблон» определяет ссылку на один из шаблонов, указанных в онтологии о проектировании интерфейса, он может дополняться новым шаблонами. «Шаблон» - это указатель на то, при каких шаблонах интерфейса может быть выбран и реализован данный элемент интерфейса. У всех элементов есть шаблон по умолчанию. Онтология шаблонов:

Шаблоны {

~set Шаблон {

~set -> Элемент интерфейса {…}

~copy -> Информация о шаблоне {…}

}

}

На рисунке lACPaaS.

9 представлен фрагмент онтологии модели интерфейса на платформе ▼    Информация о попьзова1епе (СПИСОК) т Самостоятельно вносимая информации (СПИСОК) 0 Возраст (сорт: целое) ([!] 'onemm') (all) ► Уровень владения (р] 'cooymm') (ref-new) ► Физические ограничения ([=] 'оорутт') (ref-new) описать элемент списка: описать элемент списка: ▼    Сохраненные интерфейсы {СПИСОК} V Имя сервиса * СПИСОК) ► Размещение элементов ([=] 'cooymm') (ref-new) ► Внеиний вид элементов ( = 'copy') (ref-new) ► Шаблон ([=] 'copymm') (ref-new) ► Вычисляемая информация о поведении пользователя ( = 'сору) ► Общий CSS ([=] 'copymm') (ref-new) описать элемент списка' Рисунок 9 - Фрагмент онтологии модели интерфейса

5    Онтология модели пользователя

Для генерации окончательного вида интерфейса большое значение имеют данные, индивидуально характеризующие пользователя интерфейса. Для этого предусмотрена онтология модели пользователя, в которой предусмотрены специальные критерии, помогающие выделить индивидуальные параметры пользователя и содержащиеся в информации о пользователе. «Модель пользователей» включает: {Характеристики пользователей, Вычисляемые характеристики в процессе работы, Особенности реализации, Источники}.

Модели пользователей {

~set Модель {

~copy Характеристики пользователей {…}

~copy Вычисляемые характеристики в процессе работы {…}

~copy Особенности реализации {…}

~copy Источники {…}

}

}

«Характеристики пользователей» включают данные о пользователе: {Возраст, Уровень владения, Физические ограничения}.

Характеристики пользователей {

~set Пользователь {

~copy Возраст {…}

~copy Уровень владения {…}

~copy Физические ограничения {…}

}

}

«Особенности реализации» содержат «Нерекомендуемые элементы» к использованию в рамках данной модели и «Рекомендуемые элементы».

Особенности реализации {

~copymm Нерекомендуемые элементы

~ copy Рекомендуемые элементы

}

«Нерекомендуемые элементы» содержат список элементов интерфейса, которые не рекомендуется использовать в модели. Приоритет генерации у элементов данного списка меньше, чем у других элементов. Каждый такой элемент интерфейса описывается по аналогии с обычным элементом интерфейса, представленным ранее:

Нерекомендуемые элементы { ~set -> Элемент интерфейса

}

«Рекомендуемые элементы» определяют набор стилей и общих элементов, которые будут присущи данной модели интерфейса:

Рекомендуемые элементы {

~copymm -> Common Elements

~ copy -> CSS

}

Common Elements и CSS определяются так же как в онтологии базы WIMP -элементов (см. раздел 3). На рисунке 10 представлен фрагмент онтологии «Модель пользователя», реализованный на платформе lACPaaS.

Т Модели пользователей * [СПИСОК]

V Модель {СПИСОК}

• ▼ Характеэистити пользователей * СПИСОК}

• ▼ Пользователь * {СПИСОК}.

► Возраст ([=] 'copymm’) (ref-new)

► Уровень владения ([=] 'copymm') (ref-new)

► Физические ограничения ([=] 'copymm') (ref-new)

описать элемент списка:

описать элемент списка:

• ► Вычисляемые характеристики в процессе работы ([=] 'copymm') (ref-new)

• ▼ Особенности реализации {СПИСОК}

► Нерекомендуемые элементы * ([=] 'copymm') (ref-new)

► Рекомендуемые элементы * ( = 'copy') (ref-new)

описать элемент списка:

► >• Источники ([=] 'copymm') (ref-newj описать элемент списка:

описать элемент списка:

Рисунок 10 - Фрагмент онтологии «Модель пользователя»

Упрощённый пример генерации адаптивного интерфейса с использованием рассмотренных онтологий иллюстрирует рисунок 11. В представленной на рисунке 11 схеме строятся два варианта интерфейса: на основе примера онтологии ПрО (онтологии диагностики) и адаптации по устройству (ПК или смартфон).

Адаптация 1       ______________________________________________________________

Онтология предметной области (диагностики)

▼ *• * Комплекс диагностических лэ/знаков {СПИСОК! .

▼ >• -< совместимости элементов [АГЬТЕРНАТИВА)

О * любой (тип: строковое) ( = ’copy") (ref-new)

О * все (тип: строковое) ( = 'copy1) (ref-new)

v * минимальное количество (сорт: целое) * (! 'ore')

► * Признак (|'| 'listmm') (all)

]► 5» * Фактор * ([+] 'seimm') (all)

► н * Заболевание (+ ’set) (all)

► >♦ * Группа заболеваний (или Подгруппа) ([+] 'seimm'’

Интерфейс 1

Модель пользователя Возраст: 20-40

Устройство

ПК

Адаптация 2

Интерфейс2

у । руппа заоолевании (или i юдгрупла) ц+j seimm

* Необходимое условие ([=] 'copymm') (ref-new) т/

Шаблон "табы'

Комплекс д. признаков

Признак

Фактор

Заболевание

Модель пользователя Возраст: 20-40

Группа заболеваний

Необходимое условие

Совместимость элементов

О любой минимальное количество

Устройство Смартфон

Рисунок 11 - Пример генерации адаптивного интерфейса

Заключение

Разработка интерфейсов редакторов БЗ является актуальной задачей в инженерии знаний. Это вытекает из требований современного этапа к разработке систем на основе знаний: БЗ должны разрабатывать и сопровождать эксперты ПрО. Учитывая разный уровень знаний экспертов в области информационных технологий, удобные и понятные редакторы знаний являются определяющим фактором включения экспертов в процесс разработки БЗ. Для автоматической генерации интерфейса редакторов БЗ используется онтологический подход, включающий разработку БЗ о проектировании WIMP -интерфейса, библиотеки WIMP -элементов, модели интерфейса. Разработанный генератор интерфейса автоматически формирует пользовательский интерфейс редактора знаний, ориентированный на конкретного пользователя.

В настоящее время на платформе IACPaaS реализованы все информационные и программные компоненты, проводится их опытная эксплуатация.