Я тут интенсивно почитал Левенчука — ЖЖ и вокруг, касательно новых стандартов и онтологии знаний, и у меня сложился ряд мыслей по этому поводу.
Во-первых, что есть сам процесс стандартизации вокруг методологий — ISO 24744 (metamodel for development methodologies). Это методологи (западные) в очередной раз резвятся. Они разочаровались в объектно-ориентированном подходе и объектно-ориентированных моделях и вместо этого придумали новую концепцию — онтологического моделирования. Объекты их разочаровали тем, что они не могут провести границу между атрибутом класса и другим классом, с которым есть отношения. А еще — атрибуты плохо отражают динамику изменений и вообще жизнь объекта. Поэтому в новой концепции нет атрибутов, равно как и самих объектов, а есть «факты».
Ну а раз такая смена парадигмы, то эти самые факты надо же как-то по-новому уметь записывать и под это дело — порождаются новые стандарты. Они хотят сделать их полностью самоописанными: ведь это — стандарт на представление знаний, а сам стандарт — безусловно знанием является, значит его должно быть можно представить в стандартной форме. Получается у них плохо, я, кстати, читая где-то на заднем плане испытал гордость за саморефлексивное ядро CustisUniversal.
Вся эта история и текущее состояние прилично освещена. Стандарт непрерывно переписывается, в новых частях — реализуются новые идеи, плохо совместимые со старыми, при этом старые части — не модернизируются, в результате, например, есть две слегка не совпадающие системы базовых типов, примеры не соответствуют описаниям и много другого знакомого и веселого. А еще — в принципе это все должно сопрягаться с ISO 24774 (life cycle management/process description) и ISO 15926 (data integration), но нормального сопряжения нет.
Что касается полезности стандарта — она сравнима с полезностью стандарта XML, или SWIFT или EdiFact. Причем тренд идет именно в эту сторону — описывается внешний формат представления, а семантику накладываешь ты сам, соответственно, всяк желающий представить свои знания в стандарте сможет для начала описать свою форму — произвольную — форму представления, а потом ей следовать. Конечно, стандартизаторы рассчитывают, что будут библиотеки стандартных форм, и никому не надо будет придумывать свою. Но я думаю, что будет как с EdiFact: Гера рассказывал, что для передачи любых документов, например, накладных там есть приличное множество форм, и если ты с каким-то поставщиком хотите обмениваться, то вы, во-первых, должны между собой договориться о конкретной форме, а дальше — каждый должен запросить своего провайдера, и это есть лишнее звено, поэтому на практике этим не пользуются… Левенчук это тоже высказывает, только по-другому, оптимистичнее. Кстати, есть другой пример — SWIFT — тоже множество форматов передачи различной финансовой информации, только когда мы делали работу с ним для Собина, выяснилось, что почему-то используется формат, где содержательных полей не хватает, поэтому многое пишется в структурированном текстовом комментарии, а вовсе не в полях.
Что касается методологии онтологий, то люди ищут даже не серебряную пулю, а святой грааль. Они хотят формально зафиксировать значения слов и понятий, чтобы дальше из них строить качественные, однозначно понимаемые знания. Они никак не могут смириться с тем, что у людей с одними и теми же словами связаны разные представления, и это мешает эффективной коммуникации.
На самом деле, способ однозначной фиксации — есть. Это — реализация в информационной системе. Если в информационной системе есть понятие «товарная группа» и у товара обязательна ссылка на группу, то все пользователи точно знают, какая группа у конкретного товара. При этом они могут возмущаться неправильным назначениям групп для конкретных товаров, но это уже — второй вопрос. Если они влиятельны, они могут или добиться изменения значения, и товар перейдет в другую группу, или потребовать завести еще один атрибут «товарная группа-2» и назначить его по другому, и тогда у товара будет сразу две группы. Аналогично, если система считает исполнение плана и бонусы по нему, то мы точно знаем, на сколько каждый менеджер исполнил свой план. Опять-таки можно говорить про несправедливость или дебилизм системы, факт измерения плана не изменится. Это, кстати, очень важная роль информационной системы, мне в свое время это на примерах показывал Гера и я проникся.
Но, как легко догадаться, фиксация через информационную систему методологам не нравится. Думаю, потому что они не могут на нее никак повлиять, для этого надо идти на поклон к программистам. Поэтому они лелеют надежду создать некоторое метаописание, на котором посвящены смогут формулировать структуры и используя их — фиксировать знания. Программистам отводится роль реализаторов, а все остальные — будут смиренно использовать, быть может, лелея мысль, что если будет очень надо — можно будет разобраться и что-нибудь поправить, и продвинутым — это будет удаваться. По-моему, такая затея обречена на провал, ибо она ставит в центр методолога, а вовсе не топ-менеджера или бизнесмена. Она говорит ему: «чтобы реализовать, а далее — изменить бизнес-процессы, вы должны будете обращаться к специалистам-методологам, которые упакуют ваши пожелания в набор онтологических знаний в соответствии со структурами». В принципе, это ничем не отличается от того, что происходит сейчас — только роль методологов играют автоматизаторы, использующие разнообразные инструменты разной сложности. По-моему, свести все это к одному, причем очень сложном, с высоким порогом входа — не есть перспективная идея.
Но все это не отменяет нового тренда — онтологического моделирования, который пытается подвинуть объектно-ориентированный подход. Стоит к нему приcмотреться, вдруг он случайно похож на то, что делаем мы — тогда можно поднимать на флаг. А если нет — понимать, чем отличаемся. И, в любом случае, в основе наверняка лежат хорошие идеи. Только не очень понятно, откуда это извлечь, из стандартов точно не получится…
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.