Спасибо за комментарий, вы подняли сразу несколько важных вопросов.
Мы уже несколько лет занимаемся созданием дата-центрических решений, в которых управление данными происходит с помощью онтологических инструментов. Пока в нашей практике нет предприятий, которые бы полностью перешли на такую архитектуру, но есть вполне убедительные примеры их реализации для конкретных и довольно сложных областей практической деятельности. Как правило, наши заказчики — крупные предприятия, которые в силу уникальности своих задач имеют дело с большим количеством не стандартного и/или самописного ПО, и думают о том, как с точки зрения архитектуры упростить его дальнейшее развитие, интеграцию и сопровождение.
Примеров проектов с открытым кодом, реализующих дата-центрические принципы, к сожалению, сходу не назову.
Вы правы, когда говорите, что разные группы пользователей видят мир по-разному. В «традиционном» подходе это приводит к созданию разных информационных представлений одних и тех же бизнес-объектов и их обработке в разных приложениях. Идея дата-центричности в сочетании с использованием онтологического моделирования как раз позволяет остаться в рамках одной связной модели, отражая несколько взглядов на каждый объект. При этом можно сохранить то общее, что видят в объекте все пользователи (начиная с названия/идентификационных данных сущности), и одновременно отразить различия — в его принадлежности типам/классам, наборе свойств, конструкции (наборе составляющих объектов).
Обычный подход к проектированию модели данных состоит, как вы верно указали, в том, чтобы построить структуру данных в хранилище, исходя из набора операций, которые с этими данными нужно будет выполнять. В онтологическом моделировании мы стараемся создавать модель так, чтобы она была наиболее близка структуре представлений бизнес-пользователей о реальности, на этапе моделирования совершенно не думая о том, в какой структуре данные будут представлены физически. Это позволяет сократить разрыв между тем, какими категориями и понятиями мыслит пользователь, и структурой данных, упрощает аналитические задачи.
Но, разумеется, на этапе проектирования хранилища мы не можем не думать о том, какой объем данных будет представлен в той или иной структуре, и как мы их будем обрабатывать. Сама по себе идея дата-центричности на этот вопрос не отвечает, но на него могут ответить производители конкретных платформ. Было бы идеально хранить всю информацию в одной графовой базе данных, но на практике это сейчас невозможно. Поэтому, например, наш продукт с логической точки зрения представляет собой мульти-модельное хранилище, которое может использовать реляционную, колоночную, документ-ориентированную или любую другую модель физического хранения для объектов разных классов. Для этого платформа подключается к множеству СУБД разных типов. На уровне настроек платформы указывается, в какой СУБД должны храниться объекты тех или иных классов. Эти настройки довольно детальны: например, если мы выбираем в качестве хранилища таблицу Postgres, мы можем использовать ее со стандартной для платформы структурой, которая не требует создания столбцов для каждого свойства (используем колонку типа jsonb), или же создать конкретные столбцы для каждого свойства и настроить по ним индексы, сегментирование и т.д. При этом колонка jsonb все равно существует — она предназначена для хранения значений тех свойств, которые будут созданы в модели «на лету», и для которых администратор еще не успел настроить мэппинг на конкретные колонки.
Конечно, это уже технические детали конкретной реализации. Идея же состоит в том, что платформа управления данными может абстрагировать приложение-клиент от физических деталей хранения информации, и в то же время обеспечить гибкость управления этими деталями для администратора платформы, отделить процесс моделирования предметной области от процесса настройки физической структуры данных. С точки зрения бизнес-приложения все данные представляют собой единый граф, а физически могут находиться где угодно.
Про черно-белое и хайп: полностью с вами согласен. Конечно, применение каждой технологии, в том числе дата-центрической архитектуры, оправдано только в определенных условиях. В нашем случае предпосылкой является очень сложная и быстро изменяющаяся модель данных, содержащая десятки тысяч типов сущностей и свойств. Но я говорю об этом уверенно, т.к. события последнего времени, включая пандемию, показали, насколько быстро могут возникать новые виды данных, критически влияющих на бизнес, насколько быстро их нужно включать в обработку в ИТ-системах. У нас есть свои «истории успеха», связанные с очень быстрой реализацией обработки сложных данных за пару недель в условиях, когда обычный процесс проектирования и реализации изменений в ИТ-системах занял бы месяцы.
И манифест, и эта статья намеренно имеют провокационную составляющую. И, конечно, словосочетание «волшебная пуля» я употребляю с иронией. Несмотря на это, все приведенные в статье и комментариях рассуждения по сути вопроса имеют рациональную основу и подкреплены практикой.
Да, один объект данных могут изменять разные приложения. Платформа должна позволять настраивать права доступа как минимум на уровне классов (типов сущностей) и свойств — например, приложение А может изменять название и адрес клиента, а приложение Б его адрес и статус.
Раз несколько приложений могут изменять одни и те же свойства одних и тех же объектов, нужен механизм получения уведомлений о таких изменениях в реальном времени. Это может быть и websocket-соединение, и уведомления через брокеры типа Kafka.
И, совершенно верно, должны персистентно храниться состояния объектов после любой операции, с возможностью получить от платформы все состояния объекта, все операции, которые его изменяли, конкретное состояние на любой момент времени.
Согласен, что есть свои резоны и в изоляции систем друг от друга и связывании через контракты. Возможно, для стабильного бизнеса, имеющего дело с не очень сложной предметной областью, такое решение оптимально.
Но в наше время для очень многих бизнесов скорость адаптации к изменениям становится критичной, а возможность быстрого сбора комплексной аналитики по внезапно возникающим запросам (отчет нужен завтра, а не через месяц!) и извлечения ценности из накопленных данных — реальной возможностью обогнать конкурентов или просто выжить. А когда гибкость важнее стабильности, стоит и ИТ-архитектуру строить так, чтобы как можно меньше зависеть от конкретных приложений, а в использовании данных иметь наибольшую свободу.
Насчет стандартной упорядочивающей модели — еще одно популярное заблуждение. Немало умных людей чуть ли не жизни положили на ее придумывание, хотя постановка такой задачи заведомо лишена смысла. История вопроса изложена у Дж. Сова в книге «Knowledge representation: Logical philosophical and computational foundations».
«Концептуальная модель» не есть «стандартная упорядочивающая модель». Наоборот, она может и должна быть уникальной для каждой локализуемой области, в которой решаются определенные задачи. Методика построения такой модели может быть до определенной степени формализована, но и тут есть множество нюансов, которые диктуют выбор разных способов моделирования в разных конкретных случаях. Критерий выбора методики, структуры самой модели — вопрос исключительно прагматический. Если построенная каким-то образом модель позволяет решить прикладную задачу с удовлетворяющей заказчика степенью точности, значит, это правильная методика и хорошая модель.
Остерна не читал, поэтому высказывать мнение об обобщенном программировании не стану; не уверен правда, что вообще можно сравнивать концептуальное моделирование с методикой программирования — слишком разные вещи. Личные вкусы есть у каждого, но чтобы обоснованно что-то критиковать, нужно в этом разбираться.
По поводу сложной структурированности, порождаемой сложностью проблемы — был бы рад увидеть пример. В любом случае, человек, приступая к решению задачи, должен ее так или иначе охватить разумом, что неизбежно влечет создание концептуальной схемы. Если этого сделать нельзя, то задача либо бессмысленна, либо не решаема. Точнее, наверное, можно заниматься гаданием на основе частичных представлений о задаче и смутных интуиций, но это уводит нас в область творчества, а не рационального познания.
Достоинство же концептуального моделирования состоит в способности отразить любой набор представлений, возникших в человеческой голове.
"единственным выходом из положения является тот или другой способ сведения таких не табличных данных к табличному виду"
крайне спорный тезис. Табличный вид — очень серьезное упрощение тех мысленных структур, в которых мыслит аналитик, и имеет непреодолимые органические недостатки. Хотя, конечно, далеко не для всех задач эти недостатки существенны.
Все проблемы со структурами данных возникают из-за того, что эти структуры строятся не на основе концептуальной модели предметной области (концептуальное моделирование — развитая дисциплина с отличным инструментарием), а "как лошадь пойдет". Точнее — как программист увидит. Потом люди удивляются, почему не удается соединить данные из одной странной таблицы с другой.
Вопрос объема выборки не имеет никакого значения, если неправильно построена модель, на основе которой делается расчет. А построить модель таким образом, чтобы она давала практически пригодные результаты в широком диапазоне условий, можно только начав процесс создания расчетной модели с концептуального моделирования.
Интерпретации-то они требуют, но это интерпретация другого уровня. Поскольку в онтологии информация представлена при помощи понятий, которыми оперирует человек, и выражена в виде фактов. Это представление намного ближе к нашему сознанию, чем колонка цифр.
Повторю, если придерживаться вашей точки зрения — то Знаниями является только то, что у человека в голове. Из этого априори следует, что не может быть способа работы с ними в ЭВМ, то есть разговор получается ни о чем.
Приведу аналогию. Человек с древних времен мечтал летать по воздуху, как птица. Проводились многочисленные эксперименты с самодельными крыльями и колокольнями, а потом наконец практические умы догадались не закицливаться на птицах и их способе полета. Появились воздушные шары, аэропланы, реактивные самолеты, ракеты… Человек до сих пор не летает, как птица, однако практической пользы получено огромное количество.
Со знаниями то же самое. Не нужно зацикливаться на воспроизведении человеческого мозга в электронной форме. Пользу можно получить и без этого.
Самое печальное в таких рассуждениях состоит в том, что они являются основанием для возврата к экселю.
Аргумент звучит так: если невозможно полностью воспроизвести человеческое мышление в ЭВМ — то не стоит пытаться использовать частичные решения, позволяющие к этому приблизиться.
Легко прийти к выводу, что нужно сидеть и ждать, пока кто-то создаст настоящий электронный мозг, а до тех пор можно со спокойной душой работать в электронных таблицах.
Конечно, ЭВМ не способна создать мысленный образ Пети, который куда-то идет. Но если в тексте сказано, что Петя пошел в школу, то благодаря онтологиям ЭВМ способна сделать вывод, что Петя — школьник. Точно таким же образом, каким сделает этот вывод человек.
Точнее, в онтологии заложен продукт человеческого знания, заключающийся в том, что если кто-то ходит в школу, то он является школьником. Машина просто применит его в конкретной ситуации.
Главное же состоит в том, что из такого способа получения выводов можно извлечь реальную пользу, и не стоит от нее отказываться потому, что это не полная эмуляция процессов, происходящих в голове.
p.s. посмотрите еще на IBM Watson. Интересная вещь.
Скромно добавлю, что с технической точки зрения тут нет особой проблемы. Никто мне не мешает в онтологии выразить сведения о том, что такой-то объект является тем-то с такой-то точки зрения. Мы это делаем на практике, например, создавая утверждения о том, что предприятие X с точки зрения закона ФЗ-123 — это опасный производственный объект, а с точки зрения пользователя, глядящего на карту такого-то масштаба, оно же является пространственным объектом, имеющим площадь. Из первого следуют определенные регламенты, применимые к этому предприятию, из второго — то, что мы его можем на карте нарисовать в виде многоугольника. При этом «точка зрения» явно указывается в определении классов, и используется при работе с моделью в информационной системе.
Тут главное смотреть на технологию как на технологию, а не догму.
А вот стройная методология, в которой все это можно описывать до внесения в ИТ-систему, очень бы не помешала. Как средство организации умов аналитиков.
Данные требуют интерпретации человеком. Excel может просуммировать столбец с суммой продаж, но это механическая операция — он ничего не «знает» о продажах. То есть, человек дважды совершает преобразование: первый раз — когда вносит знания в ЭВМ, превращая их в данные, и второй раз — когда смотрит на обработанные данные, и делает на основании столбца цифр какие-то выводы о продажах (получает новые знания).
Онтологии позволяют перенести в ЭВМ и сам процесс получения выводов. Кроме того, они позволяют вносить информацию в ЭВМ, используя именно те понятия, которые мы используем в мышлении, и воспринимать результат, представленный в тех же понятиях. В этом смысле онтологии, безусловно, являются способом машинного представления и обработки знаний.
Если же говорить о процессе человеческого мышления в целом, то понятно, что никто доподлинно не знает, что представляют собой наши «знания», как именно происходит процесс мышления (логика — это некая модель одного из аспектов мышления, не претендующая на описание того, как работает голова у человека). В этом смысле обработкой знаний сможет заниматься только такая система, которая будет воспроизводить человеческий мозг.
Однако, не стоит проявлять максимализм и говорить, что пока такая система не создана — об обработке знаний нет и речи.
Главный критерий — это практика. Если онтологии позволяют имитировать процесс принятия решения человеком в определенных ситуациях (а они позволяют), дают возможность представить знания с большим богатством структуры, с меньшей потерей информации, чем, скажем, реляционные СУБД (а они дают) — стоит использовать эти возможности.
Распознавание смысла текста — отдельная задача. Ее вполне сносно решает, например, продукт ABBYY Compreno, который позволяет получить из текста онтологию.
Если говорить о тех технологиях, с которыми мы работаем, то внутренним представлением знаний является граф, а не текст. Его можно построить руками, можно распознать из текста, а можно, наоборот, построить текст на его основе. Для работы с графом есть набор программных инструментов.
Один из таких инструментов — наша Система управления знаниями, которая позволяет строить запросы к базе знаний. Одним из способов построения запросов в ней является контролируемый естественный язык. Слово «контролируемый» значит, что можно написать не любую фразу, а только такую, какая дозволена правилами.
У нас есть мини демо-версия (см. trinidata.ru/asuz_demo.htm), которая позволяет построить, например, такой запрос:
Курорт, такой (-ая), что Находится в стране Россия и Имеет климат Средиземноморский.
Если ввести эту фразу в обычном поисковике, он найдет страницы, в которых указанные слова встречаются в определенных сочетаниях и с некоторой частотой. Смысл слов он при этом не анализирует. Выданные результаты будут достоверными лишь в каком-то приближении.
Наша система «знает» термины Курорт, Страна, Климат, Находится, Имеет. Запрос будет преобразован в шаблон поиска, который будет применен к графу. Результатом запроса будет 100% точный, логически обоснованный (с позиций фактов, имеющихся в системе) ответ на заданный вопрос.
Это очень простой пример, зато его можно привести в рамках комментария.
Более полную информацию, повторю, можно найти в книжке.
Золотые слова!
Как я не раз писал,
— само выделение типа «Собака» зависит от контекста (фарфоровая собака — это Собака? в одном контексте — да, в другом — нет),
— границы объекта зависят от контекста (на собаке, правда, это сложно показать),
— интенсионал, соответствующий знаку «Собака», в разных контекстах и для разных субъектов разный,
— набор конкретных объектов, являющихся Собаками, может отличаться для разных субъектов даже в пределах одного контекста и интенсионала,
— говорить о классификации Собак имеет смысл только с оглядкой на конкретную задачу, которую мы хотим решить,
— не всякий признак Собаки есть основание для классификации (на каком боку она спит — точно не основание).
Есть, конечно, техника безатрибутного моделирования, когда наличие любого признака, любое утверждение об объекте выражается классификацией. Но с практической точки зрения очень неудобно получается.
Куда удобнее, когда классификация выражает утверждения о самом объекте как таковом, а атрибуты — утверждения о его положении в мире, связях, структуре и т.д.
Кстати, пособие я обновил пару недель назад, если не видели этой версии — гляньте, там добавлено немало материала. В т.ч. о способах группировки.
В целом же, если под «нашей» парадигмой понимать RDF/OWL, то нужно разделить вопросы концептуального моделирования и ИТ. Первоначально кажется (и мне самому казалось), что OWL задает некую парадигму моделирования уже тем, что использует понятия «класс», «индивид», «свойство», использует инструментарий теории множеств. Сейчас я пришел к выводу, что никто не заставляет нас так думать.
Иными словами, на уровне концептуальной модели мы можем мыслить так, как нам удобно.
Можем думать о типах, имеющих интенсионал (подразумеваемое значение) и экстенсионал (набор объектов, которые ему соответствуют).
Можем думать о множествах.
Можем думать о коллекциях.
И на этом уровне совершенно «не париться» за то, как это будет выражено средствами ИТ.
Далее, когда доходит дело до представления модели, начинаем смотреть на возможности OWL — действительно весьма ограниченные (хотя, с другой стороны, и в таком объеме до сих пор мало используемые). И тут нам приходится выбрать способ технического представления тех или иных наших измышлений. Пару рецептов на эту тему я описывал.
Но, самое главное — от того, что и тип, и множество превратились в owl:Class, в концептуальной модели ничего не изменилось. Мы можем с этим owl:Class'ом оперировать как с типом, а можем — как с множеством. Можем подразумевать у него интенсионал, а можем и не подразумевать, а просто механически объединить какие-то объекты.
Есть конкретные технологии, которые позволяют представлять концептуальные модели в электронной форме и оперировать ими. Чтобы понять, как это выглядит на практике — нужно углубляться в детали, которые в книжке описаны. Тогда станет понятно, что машина может на этих технологиях делать, а что — не может.
Например, машина может делать логические выводы в духе «Все люди смертны, Иван — человек, значит — Иван смертен» (уровень сложности как условий, так и получаемых результатов практически не ограничен).
Следовательно, я могу известные мне факты (мои знания) записать в электронной форме в виде вот таких аксиом, и машина за меня сделает выводы. Это одна из граней управления знаниями.
Для того, чтобы такие вещи работали, крайне важно построить такую концептуальную модель, логические вычисления на которой будут давать осмысленные выводы. Для этого нужны методики моделирования, в которых важную роль играют вопросы группировки объектов. Пост посвящен возникающим при этом проблемам, то есть это теоретическое рассуждение, имеющее конкретные практические применения.
У Джона Sowa есть такая классификация способов группировки:
— Коллекция: составной объект, включающий разнородные, не обязательно исчисляемые, не обязательно четко разделяемые части. Пример: куриный суп с клецками.
— Множество: совокупность однородных, исчисляемых объектов.
— Тип: произвольная группа объектов, которую аналитик счел нужным выделить по какому-либо основанию.
— Категории: типы, используемые с целью классификации.
Мутно у него написано про категории, а в остальном — классификация полезная.
Если говорить о типах, как раз становится понятна та мысль, которую доносит автор поста. Выделяя тип, мы подразумеваем некую идею — это интенсионал; те объекты, которые соответствуют этой идее — экстенсионал.
Понятно, что экстенсионал одного и того же типа может быть различным для разных субъектов.
Интенсионалу мы присваиваем знак — например, слово «собака». Также понятно, что в разных контекстах интенсионал одного и того же знака может быть разным.
На мой взгляд, это ставит все на свои места.
В том числе, из этого следует, что задачи типизации, классификации, категорирования никогда не должны решаться вне практического контекста.
С точки зрения обобщенного математического описания — все классно и правильно.
Но обобщенные математическое описания интересны только математикам.
Прикладные задачи таким образом не решаются.
С точки зрения прикладной модели, реализованной в вычислительной системе, нет ничего противоестественного в том, чтобы считать событие объектом. Ввести классификацию событий, и шаблоны их описания, которые содержат, например, указание на задействованных в нем субъектов и объекты, конкретные параметры их конфигурации или состояния, измененные событием, и т.д. На такой модели можно будет вычислить последствия события, обнаружить каскад связанных событий, и т.д.
ИСО и остальные методики моделирования, скорее, предлагают способ нескольким субъектам договориться об общем контексте, в котором они оперируют объектами, и об общих смыслах. В этом его сила, и в этом же его слабость. Сила — в том, что мы все-таки получаем возможность говорить об одних и тех же объектах с потенциально неограниченным числом субъектов. Слабость — в том, что для большинства прикладных задач в большинстве сфер это жутко неудобно (конкретно ИСОшная методика моделирования).
То есть, ИСО заменяет наш произвольный способ выделения объектов и событий на свой, предписанный.
Не соглашусь только с тем, что ИСО развязал кусок от смысла, ему приписываемого. Наоборот, он приписал ему конкретный смысл, по крайней мере на некотором высоком уровне. С этим смыслом все остальные должны согласиться. Или использовать костыли, делая вид, что согласились, а на самом деле понимают его по-своему.
Мы уже несколько лет занимаемся созданием дата-центрических решений, в которых управление данными происходит с помощью онтологических инструментов. Пока в нашей практике нет предприятий, которые бы полностью перешли на такую архитектуру, но есть вполне убедительные примеры их реализации для конкретных и довольно сложных областей практической деятельности. Как правило, наши заказчики — крупные предприятия, которые в силу уникальности своих задач имеют дело с большим количеством не стандартного и/или самописного ПО, и думают о том, как с точки зрения архитектуры упростить его дальнейшее развитие, интеграцию и сопровождение.
Примеров проектов с открытым кодом, реализующих дата-центрические принципы, к сожалению, сходу не назову.
Вы правы, когда говорите, что разные группы пользователей видят мир по-разному. В «традиционном» подходе это приводит к созданию разных информационных представлений одних и тех же бизнес-объектов и их обработке в разных приложениях. Идея дата-центричности в сочетании с использованием онтологического моделирования как раз позволяет остаться в рамках одной связной модели, отражая несколько взглядов на каждый объект. При этом можно сохранить то общее, что видят в объекте все пользователи (начиная с названия/идентификационных данных сущности), и одновременно отразить различия — в его принадлежности типам/классам, наборе свойств, конструкции (наборе составляющих объектов).
Обычный подход к проектированию модели данных состоит, как вы верно указали, в том, чтобы построить структуру данных в хранилище, исходя из набора операций, которые с этими данными нужно будет выполнять. В онтологическом моделировании мы стараемся создавать модель так, чтобы она была наиболее близка структуре представлений бизнес-пользователей о реальности, на этапе моделирования совершенно не думая о том, в какой структуре данные будут представлены физически. Это позволяет сократить разрыв между тем, какими категориями и понятиями мыслит пользователь, и структурой данных, упрощает аналитические задачи.
Но, разумеется, на этапе проектирования хранилища мы не можем не думать о том, какой объем данных будет представлен в той или иной структуре, и как мы их будем обрабатывать. Сама по себе идея дата-центричности на этот вопрос не отвечает, но на него могут ответить производители конкретных платформ. Было бы идеально хранить всю информацию в одной графовой базе данных, но на практике это сейчас невозможно. Поэтому, например, наш продукт с логической точки зрения представляет собой мульти-модельное хранилище, которое может использовать реляционную, колоночную, документ-ориентированную или любую другую модель физического хранения для объектов разных классов. Для этого платформа подключается к множеству СУБД разных типов. На уровне настроек платформы указывается, в какой СУБД должны храниться объекты тех или иных классов. Эти настройки довольно детальны: например, если мы выбираем в качестве хранилища таблицу Postgres, мы можем использовать ее со стандартной для платформы структурой, которая не требует создания столбцов для каждого свойства (используем колонку типа jsonb), или же создать конкретные столбцы для каждого свойства и настроить по ним индексы, сегментирование и т.д. При этом колонка jsonb все равно существует — она предназначена для хранения значений тех свойств, которые будут созданы в модели «на лету», и для которых администратор еще не успел настроить мэппинг на конкретные колонки.
Конечно, это уже технические детали конкретной реализации. Идея же состоит в том, что платформа управления данными может абстрагировать приложение-клиент от физических деталей хранения информации, и в то же время обеспечить гибкость управления этими деталями для администратора платформы, отделить процесс моделирования предметной области от процесса настройки физической структуры данных. С точки зрения бизнес-приложения все данные представляют собой единый граф, а физически могут находиться где угодно.
Про черно-белое и хайп: полностью с вами согласен. Конечно, применение каждой технологии, в том числе дата-центрической архитектуры, оправдано только в определенных условиях. В нашем случае предпосылкой является очень сложная и быстро изменяющаяся модель данных, содержащая десятки тысяч типов сущностей и свойств. Но я говорю об этом уверенно, т.к. события последнего времени, включая пандемию, показали, насколько быстро могут возникать новые виды данных, критически влияющих на бизнес, насколько быстро их нужно включать в обработку в ИТ-системах. У нас есть свои «истории успеха», связанные с очень быстрой реализацией обработки сложных данных за пару недель в условиях, когда обычный процесс проектирования и реализации изменений в ИТ-системах занял бы месяцы.
И манифест, и эта статья намеренно имеют провокационную составляющую. И, конечно, словосочетание «волшебная пуля» я употребляю с иронией. Несмотря на это, все приведенные в статье и комментариях рассуждения по сути вопроса имеют рациональную основу и подкреплены практикой.
Раз несколько приложений могут изменять одни и те же свойства одних и тех же объектов, нужен механизм получения уведомлений о таких изменениях в реальном времени. Это может быть и websocket-соединение, и уведомления через брокеры типа Kafka.
И, совершенно верно, должны персистентно храниться состояния объектов после любой операции, с возможностью получить от платформы все состояния объекта, все операции, которые его изменяли, конкретное состояние на любой момент времени.
Но в наше время для очень многих бизнесов скорость адаптации к изменениям становится критичной, а возможность быстрого сбора комплексной аналитики по внезапно возникающим запросам (отчет нужен завтра, а не через месяц!) и извлечения ценности из накопленных данных — реальной возможностью обогнать конкурентов или просто выжить. А когда гибкость важнее стабильности, стоит и ИТ-архитектуру строить так, чтобы как можно меньше зависеть от конкретных приложений, а в использовании данных иметь наибольшую свободу.
«Концептуальная модель» не есть «стандартная упорядочивающая модель». Наоборот, она может и должна быть уникальной для каждой локализуемой области, в которой решаются определенные задачи. Методика построения такой модели может быть до определенной степени формализована, но и тут есть множество нюансов, которые диктуют выбор разных способов моделирования в разных конкретных случаях. Критерий выбора методики, структуры самой модели — вопрос исключительно прагматический. Если построенная каким-то образом модель позволяет решить прикладную задачу с удовлетворяющей заказчика степенью точности, значит, это правильная методика и хорошая модель.
Остерна не читал, поэтому высказывать мнение об обобщенном программировании не стану; не уверен правда, что вообще можно сравнивать концептуальное моделирование с методикой программирования — слишком разные вещи. Личные вкусы есть у каждого, но чтобы обоснованно что-то критиковать, нужно в этом разбираться.
По поводу сложной структурированности, порождаемой сложностью проблемы — был бы рад увидеть пример. В любом случае, человек, приступая к решению задачи, должен ее так или иначе охватить разумом, что неизбежно влечет создание концептуальной схемы. Если этого сделать нельзя, то задача либо бессмысленна, либо не решаема. Точнее, наверное, можно заниматься гаданием на основе частичных представлений о задаче и смутных интуиций, но это уводит нас в область творчества, а не рационального познания.
Достоинство же концептуального моделирования состоит в способности отразить любой набор представлений, возникших в человеческой голове.
Все проблемы со структурами данных возникают из-за того, что эти структуры строятся не на основе концептуальной модели предметной области (концептуальное моделирование — развитая дисциплина с отличным инструментарием), а "как лошадь пойдет". Точнее — как программист увидит. Потом люди удивляются, почему не удается соединить данные из одной странной таблицы с другой.
Вопрос объема выборки не имеет никакого значения, если неправильно построена модель, на основе которой делается расчет. А построить модель таким образом, чтобы она давала практически пригодные результаты в широком диапазоне условий, можно только начав процесс создания расчетной модели с концептуального моделирования.
Повторю, если придерживаться вашей точки зрения — то Знаниями является только то, что у человека в голове. Из этого априори следует, что не может быть способа работы с ними в ЭВМ, то есть разговор получается ни о чем.
Приведу аналогию. Человек с древних времен мечтал летать по воздуху, как птица. Проводились многочисленные эксперименты с самодельными крыльями и колокольнями, а потом наконец практические умы догадались не закицливаться на птицах и их способе полета. Появились воздушные шары, аэропланы, реактивные самолеты, ракеты… Человек до сих пор не летает, как птица, однако практической пользы получено огромное количество.
Со знаниями то же самое. Не нужно зацикливаться на воспроизведении человеческого мозга в электронной форме. Пользу можно получить и без этого.
Аргумент звучит так: если невозможно полностью воспроизвести человеческое мышление в ЭВМ — то не стоит пытаться использовать частичные решения, позволяющие к этому приблизиться.
Легко прийти к выводу, что нужно сидеть и ждать, пока кто-то создаст настоящий электронный мозг, а до тех пор можно со спокойной душой работать в электронных таблицах.
Конечно, ЭВМ не способна создать мысленный образ Пети, который куда-то идет. Но если в тексте сказано, что Петя пошел в школу, то благодаря онтологиям ЭВМ способна сделать вывод, что Петя — школьник. Точно таким же образом, каким сделает этот вывод человек.
Точнее, в онтологии заложен продукт человеческого знания, заключающийся в том, что если кто-то ходит в школу, то он является школьником. Машина просто применит его в конкретной ситуации.
Главное же состоит в том, что из такого способа получения выводов можно извлечь реальную пользу, и не стоит от нее отказываться потому, что это не полная эмуляция процессов, происходящих в голове.
p.s. посмотрите еще на IBM Watson. Интересная вещь.
Тут главное смотреть на технологию как на технологию, а не догму.
А вот стройная методология, в которой все это можно описывать до внесения в ИТ-систему, очень бы не помешала. Как средство организации умов аналитиков.
Данные требуют интерпретации человеком. Excel может просуммировать столбец с суммой продаж, но это механическая операция — он ничего не «знает» о продажах. То есть, человек дважды совершает преобразование: первый раз — когда вносит знания в ЭВМ, превращая их в данные, и второй раз — когда смотрит на обработанные данные, и делает на основании столбца цифр какие-то выводы о продажах (получает новые знания).
Онтологии позволяют перенести в ЭВМ и сам процесс получения выводов. Кроме того, они позволяют вносить информацию в ЭВМ, используя именно те понятия, которые мы используем в мышлении, и воспринимать результат, представленный в тех же понятиях. В этом смысле онтологии, безусловно, являются способом машинного представления и обработки знаний.
Если же говорить о процессе человеческого мышления в целом, то понятно, что никто доподлинно не знает, что представляют собой наши «знания», как именно происходит процесс мышления (логика — это некая модель одного из аспектов мышления, не претендующая на описание того, как работает голова у человека). В этом смысле обработкой знаний сможет заниматься только такая система, которая будет воспроизводить человеческий мозг.
Однако, не стоит проявлять максимализм и говорить, что пока такая система не создана — об обработке знаний нет и речи.
Главный критерий — это практика. Если онтологии позволяют имитировать процесс принятия решения человеком в определенных ситуациях (а они позволяют), дают возможность представить знания с большим богатством структуры, с меньшей потерей информации, чем, скажем, реляционные СУБД (а они дают) — стоит использовать эти возможности.
Если говорить о тех технологиях, с которыми мы работаем, то внутренним представлением знаний является граф, а не текст. Его можно построить руками, можно распознать из текста, а можно, наоборот, построить текст на его основе. Для работы с графом есть набор программных инструментов.
Один из таких инструментов — наша Система управления знаниями, которая позволяет строить запросы к базе знаний. Одним из способов построения запросов в ней является контролируемый естественный язык. Слово «контролируемый» значит, что можно написать не любую фразу, а только такую, какая дозволена правилами.
У нас есть мини демо-версия (см. trinidata.ru/asuz_demo.htm), которая позволяет построить, например, такой запрос:
Курорт, такой (-ая), что Находится в стране Россия и Имеет климат Средиземноморский.Если ввести эту фразу в обычном поисковике, он найдет страницы, в которых указанные слова встречаются в определенных сочетаниях и с некоторой частотой. Смысл слов он при этом не анализирует. Выданные результаты будут достоверными лишь в каком-то приближении.
Наша система «знает» термины Курорт, Страна, Климат, Находится, Имеет. Запрос будет преобразован в шаблон поиска, который будет применен к графу. Результатом запроса будет 100% точный, логически обоснованный (с позиций фактов, имеющихся в системе) ответ на заданный вопрос.
Это очень простой пример, зато его можно привести в рамках комментария.
Более полную информацию, повторю, можно найти в книжке.
Как я не раз писал,
— само выделение типа «Собака» зависит от контекста (фарфоровая собака — это Собака? в одном контексте — да, в другом — нет),
— границы объекта зависят от контекста (на собаке, правда, это сложно показать),
— интенсионал, соответствующий знаку «Собака», в разных контекстах и для разных субъектов разный,
— набор конкретных объектов, являющихся Собаками, может отличаться для разных субъектов даже в пределах одного контекста и интенсионала,
— говорить о классификации Собак имеет смысл только с оглядкой на конкретную задачу, которую мы хотим решить,
— не всякий признак Собаки есть основание для классификации (на каком боку она спит — точно не основание).
Есть, конечно, техника безатрибутного моделирования, когда наличие любого признака, любое утверждение об объекте выражается классификацией. Но с практической точки зрения очень неудобно получается.
Куда удобнее, когда классификация выражает утверждения о самом объекте как таковом, а атрибуты — утверждения о его положении в мире, связях, структуре и т.д.
В целом же, если под «нашей» парадигмой понимать RDF/OWL, то нужно разделить вопросы концептуального моделирования и ИТ. Первоначально кажется (и мне самому казалось), что OWL задает некую парадигму моделирования уже тем, что использует понятия «класс», «индивид», «свойство», использует инструментарий теории множеств. Сейчас я пришел к выводу, что никто не заставляет нас так думать.
Иными словами, на уровне концептуальной модели мы можем мыслить так, как нам удобно.
Можем думать о типах, имеющих интенсионал (подразумеваемое значение) и экстенсионал (набор объектов, которые ему соответствуют).
Можем думать о множествах.
Можем думать о коллекциях.
И на этом уровне совершенно «не париться» за то, как это будет выражено средствами ИТ.
Далее, когда доходит дело до представления модели, начинаем смотреть на возможности OWL — действительно весьма ограниченные (хотя, с другой стороны, и в таком объеме до сих пор мало используемые). И тут нам приходится выбрать способ технического представления тех или иных наших измышлений. Пару рецептов на эту тему я описывал.
Но, самое главное — от того, что и тип, и множество превратились в owl:Class, в концептуальной модели ничего не изменилось. Мы можем с этим owl:Class'ом оперировать как с типом, а можем — как с множеством. Можем подразумевать у него интенсионал, а можем и не подразумевать, а просто механически объединить какие-то объекты.
Например, машина может делать логические выводы в духе «Все люди смертны, Иван — человек, значит — Иван смертен» (уровень сложности как условий, так и получаемых результатов практически не ограничен).
Следовательно, я могу известные мне факты (мои знания) записать в электронной форме в виде вот таких аксиом, и машина за меня сделает выводы. Это одна из граней управления знаниями.
Для того, чтобы такие вещи работали, крайне важно построить такую концептуальную модель, логические вычисления на которой будут давать осмысленные выводы. Для этого нужны методики моделирования, в которых важную роль играют вопросы группировки объектов. Пост посвящен возникающим при этом проблемам, то есть это теоретическое рассуждение, имеющее конкретные практические применения.
— Коллекция: составной объект, включающий разнородные, не обязательно исчисляемые, не обязательно четко разделяемые части. Пример: куриный суп с клецками.
— Множество: совокупность однородных, исчисляемых объектов.
— Тип: произвольная группа объектов, которую аналитик счел нужным выделить по какому-либо основанию.
— Категории: типы, используемые с целью классификации.
Мутно у него написано про категории, а в остальном — классификация полезная.
Если говорить о типах, как раз становится понятна та мысль, которую доносит автор поста. Выделяя тип, мы подразумеваем некую идею — это интенсионал; те объекты, которые соответствуют этой идее — экстенсионал.
Понятно, что экстенсионал одного и того же типа может быть различным для разных субъектов.
Интенсионалу мы присваиваем знак — например, слово «собака». Также понятно, что в разных контекстах интенсионал одного и того же знака может быть разным.
На мой взгляд, это ставит все на свои места.
В том числе, из этого следует, что задачи типизации, классификации, категорирования никогда не должны решаться вне практического контекста.
Но обобщенные математическое описания интересны только математикам.
Прикладные задачи таким образом не решаются.
С точки зрения прикладной модели, реализованной в вычислительной системе, нет ничего противоестественного в том, чтобы считать событие объектом. Ввести классификацию событий, и шаблоны их описания, которые содержат, например, указание на задействованных в нем субъектов и объекты, конкретные параметры их конфигурации или состояния, измененные событием, и т.д. На такой модели можно будет вычислить последствия события, обнаружить каскад связанных событий, и т.д.
То есть, ИСО заменяет наш произвольный способ выделения объектов и событий на свой, предписанный.
Не соглашусь только с тем, что ИСО развязал кусок от смысла, ему приписываемого. Наоборот, он приписал ему конкретный смысл, по крайней мере на некотором высоком уровне. С этим смыслом все остальные должны согласиться. Или использовать костыли, делая вид, что согласились, а на самом деле понимают его по-своему.