Формальная модель онтологии словарь простой пассивный активный. Онтологический инжиниринг и модель данных

Краткий ответ на экзаменационный вопрос по курсу СИИ - системы искусственного интеллекта (все вопросы).

Онтология - формальная спецификация разделяемой концептуальной модели.

O={C, R, A}, где

• O - онтология,
• С - совокупность концептов предметной области,
• R - совокупность отношений между ними,
• A - набор аксиом (законов и правил, которые описывают законы и принципы существования концептов).

Классификация онтологий

По глубине проработки все онтологии делятся на:

• «весомые» онтологии (Heavy-weighted), содержащие аксиомы {C, R, A}
• «легкие» (Light-weighted), их не содержащие {C, R}

По уровню обобщения можно выделить следующие 4 категории онтологий:

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

Формальная модель онтологии

О = ,

• Х – конечное множество концептов предметной области,
• R – конечное множество отношений между концептами,
• Ф – конечно множество функций интерпретации, заданных в онтологии.

Ограничения на X – конечность и не пустота. R, Ф – конечные, но иногда могут быть пустыми.

Пусть R = 0, Ф = 0. Тогда онтология Х трансформируется в простой словарь:

O = V = .

В случае R = 0, Ф!= 0 каждому элементу из Х может быть поставлена в соответствие функция интерпретации f из Ф.

Х = Х1 V Х2, где

• Х1 – множество интерпретируемых терминов,
• Х2 – множество интерпретирующих терминов.

Эта страница представляет собой главу из нашего методического пособия
"Введение в онтологическое моделирование "
(нажмите для перехода к полной версии пособия в формате PDF).

Писателям-фантастам XX века казалось, что развитие вычислительных машин приведет к появлению интеллектуальных помощников человека, которые будут решать за него многие мыслительные задачи. Возможности сегодняшней техники превышают самые смелые прогнозы многих из этих авторов: компьютер умещается на ладони, всемирная сеть доступна практически везде. При этом для решения аналитических задач мы в большинстве случаев по-прежнему пользуемся в лучшем случае электронными таблицами вроде Excel. Это особенно заметно в бизнес-среде, где цена (не)правильно принятого решения имеет совершенно осязаемый эквивалент в виде многомиллиардных прибылей или убытков. Тем не менее, развитие информационной инфраструктуры бизнеса завязло на пути создания крупных «трехбуквенных систем» (ERP, CRM и т.д.), на которые тратятся огромные средства, но которые не способны дать организации-владельцу ничего особенно «интеллектуального». Современные системы «бизнес-аналитики» (BI) в основном заняты вычислением значений количественных показателей, часто имеющих весьма слабое отношение к описанию реальности, и манипулированию ими.

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

Еще рельефнее видны методологические проблемы при попытках решать оптимизационные задачи количественными методами. Типичный подход к этому вопросу состоит в формулировании «целевой функции», которая представляет собой описание какого-либо качественного состояния системы, представленного в виде числа – например, «обеспеченность населения такими-то услугами». Далее, также в количественной форме, задаются ограничения, варьируемые параметры, и после вычислений получается некий набор «оптимальных» решений. Однако их практическое воплощение часто приводит к результатам, противоположным поставленным целям, или имеет серьезные побочные последствия. Например, легко может оказаться, что «средняя температура по больнице» – обеспеченность услугами – достигла нужных значений, но определенным группам населения они стали вовсе недоступны. Или же качество этих услуг снизилось настолько, что они практически потеряли смысл для потребителей. Легко понять, что корень проблемы лежит в слишком серьезных модельных допущениях, которые были сделаны при формализации целевого параметра.

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

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

Что же нужно сделать для того, чтобы компьютер стал по-настоящему помогать нам в решении интеллектуальных бизнес-задач, смог поддерживать принятие решений в любых сферах? Необходимо вдохнуть в него «искру разума», то есть научить его «думать», как мы. Фактически, для этого нужно воспроизвести в цифровом представлении те информационные структуры и процессы, которыми мы сами пользуемся в процессе мышления: понятийный аппарат, логические рассуждения. Тогда мы сможем реализовать и процессы обработки этих структур, то есть имитировать на компьютере отдельные фрагменты наших когнитивных способностей. После этого, получив определенные результаты, мы сможем критически посмотреть на смоделированные структуры и процессы, и улучшить их. В сочетании с недоступной человеку способностью вычислительных машин к быстрой обработке огромных объемов информации, такой подход обещает дать небывало высокий уровень качества поддержки принятия решений со стороны информационных систем.

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

Одна из главных особенностей человеческого сознания состоит в том, что оно лениво. Наш мозг отсекает все «лишнее», сводя наше представление о событиях и явлениях к довольно простым определениям. Мы видим только черное и белое, и принимаем решения, исключив из рассмотрения подавляющее большинство объективной информации.

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

Главный принцип качественной аналитики, управления, основанного на знаниях, звучит так: НЕ УПРОЩАТЬ модель без необходимости.

Онтологическое моделирование: цели и средства

К сожалению, распространенные сегодня компьютерные технологии не благоприятствуют реализации этого принципа. Если в качестве инструмента анализа нам доступен только Excel или реляционные базы данных – описание бизнеса неизбежно придется сводить к ограниченному набору числовых показателей. Поэтому одной из наиболее актуальных проблем развития ИТ в настоящий момент является доведение до широкой промышленной эксплуатации таких технологий, которые позволяют строить действительно сложные и комплексные информационные модели, и решать с их помощью те оптимизационные, аналитические, оперативные задачи, перед которыми другие технические средства оказываются бессильны.

Многообещающим, но несколько недооцененным на сегодняшний день направлением решения этой задачи является использование так называемых семантических технологий. Идеи автоматизированной обработки концептуализированного знания неоднократно выдвигались мыслителями начиная с эпохи Возрождения, ограниченно использовались в лучшие годы советской плановой экономики, но до действительно функционального воплощения доросли только сейчас. На сегодняшний день созданы все необходимые компоненты методики и технологий, необходимых для работы с онтологическими моделями, которые являются предметом обработки с помощью семантических технологий. Слово «онтология» означает совокупность знаний; термин «семантические технологии» подчеркивает тот факт, что они обеспечивают работу со смыслом информации. Таким образом, переход с традиционных ИТ на семантические технологии является переходом от работы с данными к работе со знаниями. Разница между этими двумя терминами, которые здесь мы используем исключительно в применении к содержанию информационных систем, подчеркивает отличие в способе использования информации: для восприятия и использования данных необходим человек, субъект, которому приходится выполнять при этом операцию осмысления, выявления смысла данных, и его переноса на интересующую часть реальности. Знания же могут восприниматься непосредственно, так как они уже представлены при помощи того понятийного аппарата, которым пользуется человек. Кроме того, с представленными в электронном виде знаниями (онтологиями) могут выполняться и полностью автоматические операции – получение логических выводов. Результатом этого процесса являются новые знания.

Аналитики Gartner называли семантические технологии одним из наиболее многообещающих ИТ-трендов 2013 года, однако их оптимизм оказался преждевременным. Почему? Все по той же причине – человек ленив, а создание семантических моделей требует серьезных умственных усилий. Тем больше выгод и преимуществ перед конкурентами получат те, кто предпримет эти усилия, и трансформирует их в реальный бизнес-результат.

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

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

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

Основные направления применения и место онтологий в решении системных и прикладных задач показано на (рис. 2.13).

Рис. 2.13.

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

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

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

Рис. 2.14.

Традиционный подход к разработке информационных систем определен в модели ANS1/SPARC и предполагает описание элементов данных на трех уровнях:

• внешний (пользовательский) уровень - определяет наиболее полезную и удобную для конкретного пользователя форму представления подмножества данных из базы данных и знаний, необходимых для выполнения стоящих перед пользователем задач. К таким данным может относиться текст, структурированная информация в виде таблиц, графика, шаблон представления информации в документе в виде разметки страницы и т.д. Таким образом, внешний уровень характеризует, фактически, особенности пользовательского интерфейса, позволяющего сформировать ожидаемый пользователем набор представляемой после обработки информации;
• промежуточный (концептуальный) уровень - содержит абстрактное представление данных. Основной акцент в представлении информации на концептуальном уровне делается на семантике (т.е. смыслового значения) данных. Именно на этом уровне архитектуры определяются сущности предметной области, их атрибуты и связи, накладываемые на данные ограничения. Концептуальный уровень не рассматривает вопросы физического хранения информации или формы ее представления пользователю, а содержит лишь логическое представление совокупности элементов данных с отображением связей между ними;
• внутренний (физический) уровень - характеризует данные в виде, воспринимаемом операционной системой или системой управления базами данных. На этом уровне описывается физическая реализация базы данных - сведения о распределении дискового пространства для хранения данных и индексов, сведения о размещении записей в файлах и таблицах базы данных, сведения о сжатии данных, выбранных методах их шифрования и т.д. Необходимость существования этого способа представления заключается в непосредственном рассмотрении способов размещения данных при реализации проектных решений.

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

Применение методов информационного анализа с формированием онтологической модели предметной области создает хорошие предпосылки для разработки качественных моделей данных.

Рис. 2.15.

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

Проработка онтологических слоев выполняется в двух направлениях:

• от прикладной онтологии к базовой - с целью поиска онтологических оснований;
• от базовой онтологии к прикладной - для гармонизации (устранения противоречий и несоответствий) онтологий.

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

Рис. 2.16.

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

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

Корректное построение моделей данных, лежащих в основе баз данных и знаний, осуществляется на основе гармонизированных онтологий, конкретизируемых от уровня базовых до прикладных. Поиск необходимых признаков элементов информации осуществляется на аналитическом этапе с использованием информационных моделей процессов, основное назначение которых - визуализация пунктов появления и движения элементов данных. Формирование информационных моделей может выполняться как с использованием инструментария структурного анализа, так и с помощью средств, реализующих объектно-ориентированный подход. В качестве одного из вариантов таких моделей могут использоваться схемы, отображающие движение информации во время реализации процессов - диаграммы потоков данных (DFD - Data Flow Diagram), пример которой для случая применения нотации Гэйна-Сарсона приведен на рис. 2.17.

Рис. 2.17.

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

Рис. 2.18.

Детализация модели данных на уровне определений до структуры базы данных на уровне атрибутов позволяет сформировать привычную схему базы данных в виде ER-модели (ER - Entity Relationship, сущность - связь), а затем и физической модели, которые непосредственно используются при создании баз данных и знаний информационных систем.

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

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

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

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

Рис. 2.19.

При выборе базовой онтологии могут рассматриваться следующие варианты:

• база знаний ОрепСус - содержит информацию из различных предметных областей, однако в качестве недостатка этой базы знаний можно указать повышенную сложность и наличие проблем с масштабируемостью;
• SUMO (Suggested Upper Merged Ontology) - свободно распространяемая онтология IEEE (Institute of Electrical and Electronics Engineers, Институт инженеров электротехники и электроники), содержащая наиболее общие и самые абстрактные концепты. Является «канонической» онтологией верхнего уровня, содержит обозримое число концептов и аксиом, имеет ясную иерархию классов, легко может быть подвергнута расширению;
• BFO (Basic Formal Ontology) - разработка общей онтологии научных исследований. Состоит из серии подчиненных онтологий различного уровня детализации. Представляет собой единую инфраструктуру для работы с трех- и четырехмерными описаниями действительности;
• ISO 15926 - стандарт представления сведений, связанных с инженерией, строительством и эксплуатацией установок непрерывного производства. К особенностям этого типа базовой онтологии можно отнести возможность учета временной составляющей объектов (40-моделирование), а также обеспечение моделирования жизненного цикла систем (а не просто текущего состояния той или иной системы). Стандарт содержит онтологическое ядро и подразумевает использование общих библиотек справочных данных для создания прикладных информационных моделей .

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

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

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

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

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

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

Выше уже отмечалось, что понятие онтологии предполагает определение и использование взаимосвязанной и взаимосогласованной совокупности трех

компонент: таксономии терминов, определений терминов и правил их обработки. Учитывая это, введем следующее определение понятия модели онтологии:

Под формальной моделью онтологии О будем понимать упорядоченную тройку вида:

X - конечное множество концептов (понятий, терминов) предметной области, которую представляет онтология О;

Конечное множество отношений между концептами (понятиями, терминами) заданной предметной области;

Ф - конечное множество функций интерпретации (аксиоматизация), заданных на концептах и/или отношениях онтологии О.

Заметим, что естественным ограничением, накладываемым на множество X, является его конечность и непустота. Иначе обстоит дело с компонентами Ф и 91 в определении онтологии О. Понятно, что и в этом случае Ф и 91 должны быть конечными множествами. Рассмотрим, однако, граничные случаи, связанные с их пустотой.

Пусть Тогда онтология О трансформируется в простой словарь:

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

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

Другой вариант соответствует случаю но Ф 0. Тогда каждому элементу множества терминов из X может быть поставлена в соответствие функция интерпретации из Ф. Формально это утверждение может быть записано следующим образом.

где - множество интерпретируемых терминов;

Множество интерпретирующих терминов.

такие что

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

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

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

Для представления модели онтологии, которая нужна для решения задач обработки информации в Интернете, очевидно, требуется отказаться от предположения

Итак, предположим, что множество отношений на концептах онтологии не пусто, и рассмотрим возможные варианты его формирования.

Для этого введем в рассмотрение специальный подкласс онтологий - простую таксономию следующим образом:

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

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

Результаты анализа частных случаев модели онтологии приведены в таблице 8.1.

Таблица 8.1. Классификация моделей онтологии

Представления множества концептов X в виде сетевой структуры;

Использования достаточно богатого множества отношений , включающего не только таксономические отношения, но и отношения, отражающие специфику конкретной предметной области, а также средства расширения множества ;

Использования декларативных и процедурных интерпретаций и отношений, включая возможность определения новых интерпретаций.

Тогда можно ввести в рассмотрение модель расширяемой онтологии и исследовать ее свойства. Однако, учитывая техническую направленность данной книги, мы не будем делать этого здесь, а желающих познакомиться с такой моделью отсылаем к работе . Как показано в этой работе, модель расширяемой онтологии является достаточно мощной для спецификации процессов формирования пространств знаний в среде Интернет. Вместе с тем и эта модель является неполной в силу своей пассивности даже там, где определены соответствующие процедурные интерпретации и введены специальные функции пополнения онтологии. Ведь единственной точкой управления активностью в такой модели является запрос на интерпретацию определенного концепта. Этот запрос выполняется всегда одинаково и инициирует запуск соответствующей процедуры. А собственно вывод ответа на запрос и/или поиск необходимой для этого информации остается вне модели и должен реализовываться другими средствами.

Учитывая вышесказанное, а также необходимость эксплицитной спецификации процессов функционирования онтологии, введем в рассмотрение понятие онтологической системы

Под формальной моделью онтологической системы будем понимать триплет вида:

Онтология верхнего уровня (метаонтология);

Множество предметных онтологий и онтологий задач предметной области;

Е - модель машины вывода, ассоциированной с онтологической системой

Использование системы онтологий и специальной машины вывода позволяет решать в такой модели различные задачи. Расширяя систему моделей можно учитывать предпочтения пользователя, а изменяя модель машины вывода, вводить специализированные критерии релевантности получаемой в процессе поиска информации и формировать специальные репозитории накопленных данных, а также пополнять при необходимости используемые онтологии, о

В модели имеются три онтологические компоненты:

Метаонтология;

Предметная онтология;

Онтология задач.

Как указывалось выше, метаонтология оперирует общими концептами и отношениями, которые не зависят от конкретной предметной области. Концептами метауровня являются общие понятия, такие как «объект», «свойство», «значение» и т. д. Тогда на уровне метаонтологии мы получаем интенсиональное описание свойств предметной онтологии и онтологии задач. Онтология метауровня является статической, что дает возможность обеспечить здесь эффективный вывод.

Предметная онтология содержит понятия, описывающие конкретную предметную область, отношения, семантически значимые для данной предметной области, и множество интерпретаций этих понятий и отношений (декларативных и процедурных). Понятия предметной области специфичны в каждой прикладной онтологии, но отношения - более универсальны. Поэтому в качестве базиса обычно выделяют такие отношения модели предметной онтологии, как partjof, kindjof, contained_in, member_of, seealso и некоторые другие.

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

Иначе обстоит дело с отношением see also. Оно обладает другой семантикой и другими свойствами. Поэтому целесообразно вводить его не декларативно, а процедурно, подобно тому, как это делается при определении новых типов в языках программирования, где поддерживаются абстрактные типы данных;

Заметим, что и отношение see_also «не вполне» транзитивно. Действительно, если предположить, что (XI то можно считать, что (XI Однако по мере увеличения длины цепочки объектов,

связанных данным отношением, справедливость транзитивного переноса свойства connected_with падает. Поэтому в случае отношения see also мы имеем дело не с отношением частичного порядка (как, например, в случае отношения is_a), а с отношением толерантности. Однако для простоты это ограничение может быть перенесено из определения отношения в функцию его интерпретации.

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

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

Рис. 8.6. Взаимосвязь между онтологиями онтологической системы

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

С активацией понятий и/или отношений, фиксирующих решаемую задачу (описание исходной ситуации);

Определением целевого состояния (ситуации);

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

Вопрос про сервисы-процессы и задачи, а также сервисы-сущности (Are Services Nouns or Verbs, http://www.zapthink.com/report.html?id=ZAPFLASH-20091014) мне напомнил про необходимость онтологического уровня рассуждений, о котором говорил Chris Partrige в своей презентации июля 2007г. "Data and process revisited: ontology driving a paradigm shift in the development of business application systems" (http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2007_07_05), но навело на другие мысли, которые я опишу тут пока несколько сумбурно.

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

SOA развивается как дисциплина, обеспечивающая гибкость "корпоративных" информационных систем. Подход интеграции данных в САПР на базе онтологических схем -- все то же самое.

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

Эти схемы огромны. В ISO 15926 изначально было порядка 50тыс. сущностей. В Gellish около того. В Dassault Systemes V6 универсальный моделер MatrixOne (на котором базируются все остальные модули V6, и который связывает все эти модули между собой и предоставляет им общую для всех базу данных) предоставляет возможность сделать SOA-архитектуру (чем гордятся) с 20тыс. классов "из коробки". Поясню: вы можете программировать, но вы должны понимать, что в вашем языке программирования есть 20 тыс. зарезервированных слов, каждое из которых что-то значит. Сравните это с изучением иностранного языка плюс вспомните, что компьютер не простит двусмысленностей и неточностей -- и вы получите представление о сложности сегодняшнего программирования. Никакая computer science пока тут рядом не стояла, пока это все вотчина software engineering.

Мне кажется, что application agnostic zone из презентации Chris Partrige уже есть. Вы еще не начали программировать свое "приложение", а вам уже дадено 20тыс. понятий. Вовсе не факт, что все эти понятия из системной архитектуры, а не предметной архитектуры. Вовсе не факт, что эти 20тыс. понятий все относятся к описанию самой V6 и ее модулей. Нет, в современных САПР вы обязательно найдете upper ontology во всей ее красе, вы найдете "полную схему мира", хотя и краткую по необходимости. В каждом современном САПР есть свой CYC, только он маленький и сводится к common sense только для инжиниринга -- там нет сведений о литературе и искусстве, медицине и политике.

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

Еще раз перепроверимся: ISO 15926 "из коробки" на верхнем уровне включает порядка 50тыс. классов. Предполагается, что вы работаете именно с ними, и там все основное и необходимое есть. Не предполагается, что вы заново создаете все понятия по мере того, как в них возникает потребность.

Есть и другое измерение этой проблемы: софт состоит сейчас из независимых кусков (можем назвать их сервисами -- даже не связывая это с SOA. Кто-то что-то где-то для нас делает, это сервис. Это совсем необязательно "объект, выполняющий метод", ОО-подход лишь один из способов об этом думать). Программирование сегодня -- это по сути связывание таких независимых кусков-сервисов для того, чтобы создать набор сервисов более высокого уровня (даже не "приложение", как об этом регулярно напоминает Алан Кей -- см., например, тред ).

Тем не менее, забудь о рефакторинге, всяк сюда входящий: внутрь кирпичей не смотрят, это и достоинство и проблема. Я думаю, если внимательно проработать 20тыс. классов MatrixOne, а также поглядеть на все дублирующие друг друга части модулей V6 и "отрефакторить" по-человечески, то можно было бы получить систему другого класса как по масштабируемости, так и по легкости освоения и сопровождения.

Итак, современное программирование -- это работа по написанию "сервисов" над огромными плохо отрефакторенными онтологиями. Уже нет "данных", есть онтологии, но работа с онтологиями по существу отстает от работы с агентской ("выполнителями", "процессорами", "модулями", сервисами, объектами-с-методами и т.д.) частью. Рост же компьютерной мощности дает возможность плюнуть на эту онтологическую грязь, "онтологический долг" (ср. technical debt из agile).

Текущее обсуждение "программирования-в-большом" (programming-in-large, http://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small) эти проблемы игнорирует, опять таки сосредотачиваясь на "языках программирования-в-большом" и тем самым сводя все изменение парадигмы к повторению истории "программирования-в-малом" для асинхронных распределенных сервисов. Мне же кажется, что акцент тут нужно делать не на том, что есть множество асинхронных распределенных сервисов, а в том, что это (включая тот факт, что сервисы эти пишутся разными людьми и отражают структуру разных предметных областей) приводит к появлению огромных слабо контролируемых онтологий и тем самым к появленю нового сорта архитектур -- "универсальных моделирующих комплексов", которые сейчас стремительно развиваются под маркой SOA.

Тем самым я рассматриваю SOA просто как способ:
-- указать на то, что подлежащие модели являются не айтишными моделями, а задающимися спецификой деятельности организации. После этого появляется эпистемологическая проблема расхождения модели и реальности, и кроме инженерной части работы возникает мыслительная часть ("полагание" онтологии) и исследовательская часть по выявлению поведения этой онтологии в реальности. Именно отсюда и родился так похожий на agile manifesto манифест SOA.
-- дать хоть какой-то набор практик жизненного цикла (software process) для программирования-в-большом. Ведь на сегодня программная инженерия говорит что-то осмысленное только про программирование-в-малом. А программирование-в-большом (которое, замечу, скрывается и внутри программирования на C++ и Java, а не только BPEL) осталось без специфичных для него практик. Вот SOA и заполняет эту брешь, уж как может.

Сама проблема "программирования в большом" для меня очень близка к тематике проектирования-конструирования. Проектирование -- это для меня полный аналог "программирования-в-большом". Ты должен собрать из (в пределе, например для ядерной подводной лодки, которую любит приводить в пример Dassault Systemes) 4 миллионов комплектующих (данных тебе в виде каталогов стандартных комплектующих главным образом, и лишь совсем чуть-чуть в виде конструируемых специально для твоего проекта особых деталей), и тем самым добиться того, чтобы эти результаты чужого труда каким-то образом заработали вместе, а вся результирующая композиция не развалилась, не взорвалась и служила долго.

Сейчас с проблемой моделирования-в-большом столкнулись модельеры, у которых встала та же самая задача modeling-in-the-large (подробнее см. megamodeling в https://gforge.inria.fr/plugins/scmsvn/viewcvs.php/*checkout*/Publications/2009/SLE-IfMDEisSol.pdf?rev=29&root=atlantic-zoos , но эти ребята из AMMA заявили об этой проблеме на конференциях MDAFA 2003/2004, и опубликовались в 2005г. http://www.springerlink.com/content/dqj98uwqp2gbu3cx/?p=c10f5251afa74af6b134631cf4dae7a1&pi=2 . У них там еще пять лет назад говорилось то, что я твержу сейчас -- "There is probably not going to be a unique monolithic modeling language (like UML 2.0) but instead an important number of small domain specific languages (DSLs) and this will only be possible if these small DSLs are well coordinated. To avoid the risk of fragmentation, we need to offer a global vision, wich can be provided by the activity of modeling in large").

Тем самым, мы наблюдаем много-много разных способов сделать language workbenches: SOA (как это ни странно), собственно language workbenches, работы типа ведущихся в группе AMMA, современные САПР с "универсальной датацентрикой" и кучерявой схемой/моделью данных/онтологией.

Это магистраль, "в большом". Это и есть текущий мейнстрим. Онтологии тут -- enabling technology.