Обсуждение

Анатолий, не встречалась ли тебе методология формирования онтологических описаний? Как научиться формировать схемы подобные схеме инженерного проекта?

Мне показалось, что вы пишете альтернативный учебник системного анализа и теории систем одновременно, нет? Месорович уже устарел? SADT-диаграммы пошли в утиль?

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

Это же разные вопросы -- про методологию формирования онтологических описаний и про "как научиться". Например, вот методология формирования онтологических описаний, написанная некторое время назад нами для ISO 15926 : http://techinvestlab.ru/files/RefDataEng/RefDataEngr_ver_2_25feb11.doc (но к моменту прочтения этого текста нужно уже довольно много знать и уметь). Вот пример последовательности чтения, чтобы смочь работать по этой методологии: http://levenchuk.com/2012/10/01/iso-15926-self-education-sequence/ Вообще, литературы море. Всё зависит от того, что хочется получить на выходе. Обычно людей не онтологии интересуют, а онтики, а это совсем другая история. Кроме того, часто людям нужно не онтологизирование, а моделирование, опять же это про другое. Моя задача в данной книжке -- дать некоторый минимум знаний про схемное/онтологичное мышление и дать некоторый минимум онтологических схем/диаграмм.

Альтернативный?! Нет, книжка совсем про другое (и я её не пишу, а переписываю: можете посмотреть текущий вариант и составить своё мнение -- ссылка в конце текста поста). У мени ни анализ, ни синтез в этой книжке: практик я не касаюсь, только рассказываю, с какими объектами работают системные инженеры. Конечно, эти объекты определяются в соответствии с системным подходом, в этом главная фишка. Содержание у меня действительно свежее (я опираюсь на стандарты последних 5-6 лет выпуска), а что касается SADT-диаграмм, то они давно пошли в утиль и их не рекомендуют сейчас использовать по совокупности причин.

И вообще, я в качестве примера привожу не онтологию, а онтику -- но этого мне пока хватает. Насчёт субстанций и акциденций, так я уже помянул факт-ориентированный подход и 4D экстенсионализм, которые от аристотелевских представлений ушли. Так что в диаграмме нет ни субстанций, ни акциденций. С другой стороны, есть некоторые неразрешимые проблемы с альфами (значок альфы на диаграмме неслучаен, и понятие альфы очень плохо выразимо в текущем её определении в OMG Essence в той же 4D экстенсиональной инженерной онтологии ISO 15926 -- но и решение этой проблемы мы пока оставим на будущее). По идее, от этого курса системноинженерного мышления есть два пути: "вниз" и "вверх" -- вниз обсуждение системноинженерных практик, вверх обсуждение "почему нет субстанций и акциденций, и что вместо них". Каждое из обсуждений -- полноценный предмет, и даже не один.

В чем причина сдачи SADT в утиль? Нас (начало 1990-х) как раз обучали системному подходу на их графической поддержке. Там все вроде очень стройно и онтологии (словарь предметной области) синтезируется естественным путем. Мне диаграммы из текста больше напомнили use case.

Эпиграф: "-- Апельсин знаешь? -- Да. -- Так вот, вертолёт на него совсем не похож". SADT -- это 1974, а начинался он вообще в 60-х. В наше время это "стройным" не считают по длинной совокупности причин. Онтология, кстати, это не словарь предметной области (ни vocabulary, ни dictionary, ни glossary). Мне казалось, что я в тексте как-то различал все эти "говорения-словарения" и "обсуждения про жизнь в натуре". Хотя есть и традиция делать онтологии по этой линии "как говорят" -- они идут на следующей ступеньке после тезаурусов по этой линии, я привёл в пример DOLCHE. На диаграмме из текста меньше всего use case, и это даже не объект-ориентированная диаграмма (а факт-ориентированная). В принципе, все диаграммы на свете сводятся к квадратикам или кружочкам (на этой диаграмме, правда, значок альфы -- но это сразу незаметно, будет объясняться позднее) и разным видам стрелочек между ними. Так что все диаграммы в каком-то смысле "похожи" и "напоминают" друг друга.

Спасибо! Посмотрю. Но мне представлялось, что ISO 15926 служит для организации обмена данными между независимыми информационными системами. А мой вопрос был связан с практикой организации общего понимания некоторой области интереса между людьми. Это, вероятно, должен быть менее формализованный подход, менее строгий подход, чем представленный в ISO 15926. На выходе хочется получить способность формировать онтологические описания, аналогичные схеме инженерного проекта. Уж очень полезная схема получилась! :)

Фон Неймановская архитектура ЭВМ - это вообще 1940-50 гг, поэтому отсылка к датам не вполне понятна, поскольку вы сейчас набиваете этот текст опираясь на всю ту же концепцию 70-летней давности. Если под онтологией вы понимаете концетуальные модели предметной области (или области знаний), то, разумеется, к своему словарю она не сводится. Но без функциональной модели, получаемой при анализе или синтезе с помощью SADT обойтись вряд ли получится. И еще я не разглядел в тексте важный вопрос: цель построения онтологии. Очевидно, что без неё исследователь будет вынужден оперировать философским, а не научным понятием с соответствующим нулевым результатом. "Выпей моря, Ксанф" (с)

Для подобных схем нужно брать язык Essence -- схема инженерного проекта ровно на этом языке и нарисована. Ещё берут архитектурные языки. Но при этом редко поминают "онтологии" и чаще говорят об описаниях практик и методов, архитектурных описаниях, описаниях деятельности и т.д. (чего язык берут, то и описывают). Про онтологии вспоминают, когда начинают спрашивать -- а на каком языке написаны все эти разные языки описания деятельности )))

Если говорить о годах, когда была сформулирована факт-ориентированная модель представления семантики, то это примерно 1905-1907 годы, работы Пирса. Смею заверить, что без SADT вполне можно обойтись. Физики не используют теорию эфира уже, хотя старые физики много лет считали, что молодёжь дурная, про какие-то относительности и кванты рассуждает -- но старые физики померли, и каюк теории эфира. Старые парадимгы умирают вместе с её носителями, это известно. Мне уже 56 лет, и я не хочу уносить свои парадигмы с собой в могилку. Монография по SADT у меня есть, но она только на память. Я стараюсь быть современным, иначе профессионально мне грош цена. С функциями современное моделирование и онтологизирование, конечно, работает -- но не как в SADT, а по-другому. Конечно, в книжке это описано. Вы бы её, кстати, почитали (ссылка в конце текста поста), многие вопросы бы отпали. Я бы надеялся, что у меня понятием онтологии будет оперировать не исследователь, а инженер. Что касается целей использования онтологии (меня на данной стадии меньше волнует её построение), то в книжке больше 300 страниц. Цель всех этих онтологических описаний/онтологических диаграмм -- задать понятия системной инженерии, системноинженерного мышления, системного подхода. Она прописана явно даже в этом обрывке текста: "В книге мы будем использовать онтологические описания/схемы/диаграммы, отражающие основные онтологические факты об отношениях объектов в предметной области системного мышления, системной инженерии, ситуационной инженерии методов и других нужных нам дисциплин. Именно эти схемы/понятийные диаграммы/онтологические описания дают ответ на вопрос “что есть в мире, что относится к системной инженерии?”. Рассуждения в книге будут строиться на основе таких схем/понятийных диаграмм/онтологических описаний. После некоторого упражнения такие схемы формируют в мозгах “рельсы мышления”, которые позволяют думать быстро — не изобретать велосипед каждый раз, когда вам нужно о подумать, например об инженерном проекте".

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

А что в тексте постинга противоречит SADT? SADT - это определённый онтологический подход к миру. Один из возможных. Если в мире видятся входы и выходы - то в SADT прямая дорога и сегодня. В альфах Работы и Технологии вполне можно использовать.

Нет, онтология вообще не про язык. И она ни разу не про борьбу. Она про то, что есть в мире -- а уж как это назвать, это вопрос отдельный. Вот есть насос, в онтологии он есть. А называть его "насос" или "pump" или "повышатель давления" -- это не онтологический вопрос, а терминологический. Если вы задаёте такой вопрос, то мне нужно как-то мой текст переработать. Я думал, что это ясно объяснил. Ан нет...

Пост абсолютно не противоречит SADT, это правда. Но "вполне можно использовать" -- я бы не рекомендовал (примерно по тем же причинам, по которым не рекомендовал бы использовать для программирования Кобол). SADT -- это Кобол архитектурных языков: -- разные его veiw плохо сочетаются, самих view маловато, нет стандартного способа расширения языка -- хуже онтологически определён, чем современные архитектурные языки, это плохо для model cheking (и это отражается на качестве софта) -- ужасен в использовании screen/page asset -- функциональные диаграммы дико путаются с процессными (развёртками во времени) -- путаница между IDEF0 и IDEF3 в доступной от NIST публичной версии проприетарного SADT, и никаких защит от этого нет -- плохо показывает обработку чего-то одного многими операциями (упор на входы-выходы каждой функции) -- плохо кладётся на use cases подход, трудней выявлять требования -- не объект-ориентирован (хотя это не для всех недостаток) Достоинства те же, что и у Кобола: -- тонны примеров, тысячи людей с опытом, литературы, учебных курсов -- воспроизводится в любом Visio и Powerpoint без проблем -- вроде бы понятен и прост (впрочем, это более чем обманчиво, как и в случае Кобола)

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

Текст о синтезе, а SADT, да и вообще построение концептуальных моделей (онтологий) - это анализ.

Вообще-то говоря, даже в software engineering создание концептуальной модели предметной области прежде всего (и всего остального потом) лежит в основе одного из методов разработки -- domain-driven development. Так что ничего особо экстраординарного там нет. Но требуется, конечно, дополнительное обучение (как и любому другому методу). Мне нужно создать концептуальную модель предметной области системной инженерии, чтобы научить студентов. Это не концептуальная модель предметной области конкретного инженерного проекта. Их построением занимаются в ходе освоения практик системной инженерии. Я сейчас не про практики самой системной инженерии говорю. У меня сейчас нет в тексте ни практик анализа, ни практик синтеза (хотя я думаю сделать небольшие раздельчики со ссылками на литературу по этим практикам). Сама идея курса -- выделить сначала кусок про основные понятия системной инженерии и потренировать людей в их различении и обзывании. Потом рассказывать про разные практики, как анализировать и синтезировать, создавать и уничтожать, транформировать и придумывать. Когда понятно, какие объекты подвергаются всем этим операциям. Да, я знаю, что у такого подхода есть большая критика, но аналогичная критика есть и у подхода одновременного рассказа про практики и их объекты.

в диаграмме нет ни субстанций, ни акциденций" Стрелочки (эманаций, свойств) от правых элементов (субстанций) к левым (акциденциям) говорят об обратном. Попробуйте стрелочки развернуть... Будет неудобно. А так думать удобно. Почему? Потому что Аристотель у нас в печёнках сидит. Это, конечно не "сами" субстанции- акциденции я имею в виду, а результат их категориального разнесения. И если от абстрактного к конкретному - восхождение, то к инженерным практикам - "вверх". А вот если от общего к частному - детализация (антоним генерализации) - то да, к практикам - вниз.