Стандарты представления знаний

Я тут интенсивно почитал Левенчука — ЖЖ и вокруг, касательно новых стандартов и онтологии знаний, и у меня сложился ряд мыслей по этому поводу.

Во-первых, что есть сам процесс стандартизации вокруг методологий — ISO 24744 (»metamodel for development methodologies»). Это методологи (западные) в очередной раз резвятся. Они разочаровались в объектно-ориентированном подходе и объектно-ориентированных моделях и вместо этого придумали новую концепцию — онтологического моделирования. Объекты их разочаровали тем, что они не могут провести границу между атрибутом класса и другим классом, с которым есть отношения. А еще — атрибуты плохо отражают динамику изменений и вообще жизнь объекта. Поэтому в новой концепции нет атрибутов, равно как и самих объектов, а есть «факты».

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

Вся эта история и текущее состояние прилично освещена. Стандарт непрерывно переписывается, в новых частях — реализуются новые идеи, плохо совместимые со старыми, при этом старые части — не модернизируются, в результате, например, есть две слегка не совпадающие системы базовых типов, примеры не соответствуют описаниям и много другого знакомого и веселого. А еще — в принципе это все должно сопрягаться с ISO 24774 (»life cycle management/process description») и ISO 15926 (»data integration»), но нормального сопряжения нет.

Что касается полезности стандарта — она сравнима с полезностью стандарта XML, или SWIFT или EdiFact. Причем тренд идет именно в эту сторону — описывается внешний формат представления, а семантику накладываешь ты сам, соответственно, всяк желающий представить свои знания в стандарте сможет для начала описать свою форму — произвольную — форму представления, а потом ей следовать. Конечно, стандартизаторы рассчитывают, что будут библиотеки стандартных форм, и никому не надо будет придумывать свою. Но я думаю, что будет как с EdiFact: как мне рассказывали, для передачи любых документов, например, накладных там есть приличное множество форм, и если ты с каким-то поставщиком хотите обмениваться, то вы, во-первых, должны между собой договориться о конкретной форме, а дальше — каждый должен запросить своего провайдера, и это есть лишнее звено, поэтому на практике этим не пользуются… Левенчук это тоже высказывает, только по-другому, оптимистичнее. Кстати, есть другой пример — SWIFT — тоже множество форматов передачи различной финансовой информации, только когда мы (давно) делали работу с ним для Собинбанка, выяснилось, что почему-то используется формат, где содержательных полей не хватает, поэтому многое пишется в структурированном текстовом комментарии, а вовсе не в полях.

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

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

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

Но все это не отменяет нового тренда — онтологического моделирования, который пытается подвинуть объектно-ориентированный подход. Стоит к нему приcмотреться, вдруг он случайно похож на то, что делаем мы — тогда можно поднимать на флаг. А если нет — понимать, чем отличаемся. И, в любом случае, в основе наверняка лежат хорошие идеи. Только не очень понятно, откуда это извлечь, из стандартов точно не получится…