Обсуждение

Здесь хотя бы формулы у бредогенератора понятные. :) Метод "нагенерировать комбинаций и приписать что-нибудь" вовсю используется в книгах по психологии (например, работы Эрика Берна), книгах по менеджменту, дурных API и наших любимых международных стандартах ("SomeRelationshipOfB is a SomeRelationshipOfA where an A is also a B"), а также многих других сферах. Но обычно вручную, с перекосами, так что и решение порождаемых таким методом проблем тоже приходится решать вручную. А так бы красиво могло быть, кому надо написать пару тысяч страниц спецификации - пишут бот_бредогенератор, а кому потом по ней работать - пишут бот_нормализатор, и наступает вселенское счастье.

Совершенно верно, любой рендеринг в нормальночеловекочитаемость обычно денормализующий (pun intended). Вот нам бы такой бредогенератор построить -- это ведь и есть генератор отчётов для онтологического софта. На входе текст на ОргЛане, на выходе -- набор человекочитаемых регламентов, положений, должностных инструкций, и всё это в виде приятно свёрстанного вебсайта. EPF Composer делает это для описания метода. А у нас должно было бы быть в общем виде. И, мне кажется, что это не должно быть труднореализуемым. Денормализаторы проще обычно, чем нормализаторы :-)

Такой вывод можно давать как пример результата, пример реализации, тестовые данные, etc. Если же он появляется в требованиях (стандарта), то проблемы гарантированы. Т.е. если у нас есть требование z = sin(x + pi/3) + log(y), то всё в порядке. Если же стандарт содержит громадную предрассчитанную на калькуляторах таблицу A33.16 со значениями z для разных (x, y), и в требованиях заявляется именно она, то ахтунг.

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

Как-то так. Из-за ещё большей денормализации, например, тот же HQDM смотрится лучше 15926-2 в качестве примера с картинками, но получается на порядок хуже в качестве верхней онтологии. Но его формат и есть книжка с картинками, так что о применении (в отличие от 15926) можно не беспокоиться.

> 1. Берем любое существительное ... А тем --- даже ластики не нужны.

Вы будете смеяться, но в Яндексе таки есть отдельный департамент, в который собрали всех менеджеров проектов, именно по принципу того, что они менеджеры :)

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