Меня включили в некоторую весьма специфическую частную переписку по поводу MBSE, аргументы сторон этой переписки были примерно следующие
( Read more... )
Я специально оговорил: -- поскольку нас не волнует decidability, то мы смело можем идти в HOL и модальные логики в плане получения формальной системы (тут нужно сказать, что текущий ISO 15926 ни разу не формальная система, и это источник вечной критики. Хотя у Клювера сотоварищи есть планы его выражения как раз в FOL в конкретном варианте синтаксиса OWL 2 -- но это пока только планы). Но это ведь только про "теоретическую основу", пользователю необязательно это видеть. -- кроме темплейтов за последний год в тусовке появилось ещё одно средство повышения уровня языка: паттерны. Что это такое, и как с ними обходиться, внятно пока не может сказать никто (несмотря на то, что буквально на днях выходит версия 1.2 нашей софтинки с поддержкой пользовательских паттернов, ибо мы формализовали и реализовали язык описания этих паттернов). Я лично думаю, что привязывать конкретный синтаксис нужно не к темплейтам, а паттернам. Это (надеюсь) будет ещё более человечно (как говорят люди из тусовки, "ближе к инженерам"), чем голые темплейты.
Остальное да, именно так: верифицироваться, отображаться и использоваться в реальных проектах.
Когда я говорю о поддержке системного подхода (понятия "система"), я и имею ввиду именно алфавит и словарь языка для людей. Именно поэтому я ссылаюсь тут не на чисто машинный ISO 15926 как высшее слово разума, а на HQDM, Мэтью Вест его правил именно с интентом сделать понятизацию "системы" более осмысленной для человеков.
Но я в затруднении, что взять за основу для конкретного синтаксиса: то ли диаграммки типа как в книжках BORO, то ли придумать чисто текстовую нотацию. А дальше этот конкретный синтаксис мэппить на онтологические паттерны, которые затем превращаются в темплейты, которые затем поднимаются в граф из сущностей части 2.
Я думаю, что мы подошли к такому месту, что нужен уже хоть какой-то конкретный синтаксис, без которого трудно будет поупражняться в моделировании, а без упражнений будет трудно сформулировать алфавит и словарь системного языка.
Потом вся эта история может повториться в прототипном подходе, но при этом значительная часть собственно "системной" работы и сопутствующей аргументации может быть выполнена на текущем, темплейтно-паттерновом поколении технологий, и перетягивание на новую (или на гибридную, т.е. "добавление" новой) понятийную теорию будет сильно полегче: будет сформулировано (оформлено, документировано) то, что нужно перетягивать.
HOL здесь не спасёт, с ней будут те же самые ляпы. Код предметной области можно проверить и отладить на самой предметной области. А для логического описания мы можем выяснить непротиворечивость, но крайне сложно проверить его адекватность описываемой ситуации.
Короче говоря, если факты сами себя обрабатывают, то это плохая обработка, а также препятствие для удобной обработки этих фактов чем-либо ещё. Мне кажется, что единственным решением является отсутствие навороченных механизмов вывода в языке. Вывод (даже прототипный) надо оставить имплементациям, и он может влиять на "циферки", но не должен влиять на базовую систему типов.
Вот мы с vvagr это и обсуждали: паттерны в ISO 15926 -- это как раз сигнатуры без аксиом (т.е. сигнатуры без подразумеваемого механизма вывода), а уж как они обрабатываются потом (поднимаемыми темплейтами ISO 15926, или рендерами экранных редакторов, или солверами из Agda) это вопрос отдельный. Так что по этому поводу, похоже, у нас консенсус, только терминология чуть разная была использована.
Всё одно стоит вопрос про то, -- как базовую систему типов отображать в конкретном синтаксисе (текстовом? графическом? что брать за основу?), и -- какие там типы считать базовыми (например, считать нечеловечьи "темпоральные части" и "функциональные физические объекты" из ISO 15926 правильными начальными типами, или "состояния" и "системные компоненты" из HQDM, или тяжело вздохнуть и сразу делать что-то своё на базе моего доклада по понятию "система" и анализа текущих архитектурных языков плюс Моделики).
В любом случае, задача при текущей постановке уже представляется обозримой и обоснованной.
Текстовый и бинарный синтаксисы, а также базовая система типов у меня есть. Потихоньку работаю над имплементициями.
Сильно разные вещи - система типов (unit, record, tag, ...) и "базовые типы для описания систем" (функциональные физические объекты, etc) как элементы стандартных библиотек.
Диаграммные представления - одну и ту же ситуацию можно представить как state diagram или flowchart. Тоже выбор библиотек.
Ну, это ещё один уровень: система типов для сериализации (у нас в .15926 это, как я понимаю, XSD+RDF). Для меня это не базовые типы, а сериализационные типы ("транспортный формат", как мы использовали OWL для представления типов ISO 15926).
Там, конечно, более тонкое отношение между семантикой сериализационного уровня и семантикой видимого людям базового уровня моделирования, тем не менее.
Так что мне нужен текстовый или графический синтаксис для представления "системы", "жизненного цикла" и прочих таких понятий системного языка. Ясно, что unit, record и tag про ЗАПИСЬ представлений о системе, но не про собственно систему (то есть мне нужен уровень, когда я могу уже не столько оговаривать, что я работаю с архитектурным описанием, а не архитектурой, с системным описанием, а не системой, сколько просто опускать слово "описание" без потери понятности и осмысленности).
Система типов решает вопросы уровня "сюда можно только число, сюда что-либо из множества cardinal_direction, а сюда только единицу измерения", для чего содержит аналоги part2:Classification. Помещение фактов под модальность тоже осуществляется там. Хорошая система типов это первый уровень формализации, а человекочитаемые нотации и транспортные форматы уже последствия.
Поверх этого может быть реализована библиотека "жизненный цикл". А также, библиотеки "пространство", "время", "единицы измерения", etc.
Без примера непонятно, увы. Где-то там внизу всегда есть "строки" и "целые". А вот как оно там растёт выше через "типы" к этим "библиотекам" -- уже мне непонятно. В ISO 15926 в этом месте тоже мутновато донельзя (типы XSD, затем 201 тип части 2 на этой базе, затем всё остальное на базе части 2).
Фишка в том, что все эти "число, cardinal_direction, единица измерения" представляют смесь того, как говорят о мире, и объектов самого мира -- то есть смесь системы репрезентации и концептуальной схемы (которая абстрактна и описывает мир, а не способ говорения о мире).
Вот и непонятно без примера, ибо никаких особых принципов по разделению всех этих возможных около-онтологических сущностей на форматы, типы, классы я пока не усматриваю. Мне понятно, что люди привыкли какими-нибудь "питоновскими словарями" выражать объекты реального мира, не задумываясь, что это означает онтологически. Но вот когда говорим о "пространстве", "времени" и "единицах измерения", хотелось бы понимать, чем они принципиально отличаются от подлежащей системы типов (ибо не о разметке же в памяти и не об языковой интерпретации -- то есть свойствах компьютера речь идёт, а о выражении тех или иных свойств мира).
Мутность и есть следствие разрозненности. Типы есть, в разных сочетаниях (EXPRESS+Part2, FOL+Part2, XSD+OWL+Part2), а системы нет.
Базовая система должна равноценно поддерживать нужные типы. В том числе: 1. Vector3d, uint32 и другие типы, значения которых выражены битами/байтами в железе, на котором крутится информационная система. 2. Такие типы как ГородЛондон или ГородОдесса, значения которых представлены в реальном (или возможном) мире, за пределами информационной системы.
Если это разные системы, то как когнитивные затраты со стороны пользователей, так и затрачиваемые машинные ресурсы увеличиваются на порядок.
Я полностью это поддерживаю, что пристыковка XML к XSD к OWL к Part 2 и потом через искусственный трюк с дублированием в части 4 типов части 2 и унаследованием ExpressString выражение всего-всего дальше -- это дурдом тот ещё. С удовольствием бы поглядел, как можно без этой головной боли справиться.
Мэтью Вест, кстати, очень жёстко пытается различать те онтологии, которые "про мир", а не не-онтологии "про то, как говорять о мире" (как говорить о мире -- это для него DOLCHE, а про мир -- это ISO 15926). Для него это кардинальное различие.
А вот Vector3D и ГородЛондон как раз из этих двух разных подходов: первое "как говорят о мире", а второе -- "про мир", и вот этот стык очень мутный.
Пару дней назад нам написали, что в нашей методологии инженерии референсных данных одновременно Москва и данные (абстрактный объект), и индивид физического объекта, а это противоречиво. Мы подискутировали, в дискуссии поучаствовал и Мэтью Вест -- когда я сказал, что "данные correspond физической Москве, и это обычный вординг iso 15926", он отметил, что "никакого correspond, ибо отношение между меткой Москва и индивидом Москва называется в стандарте representation". Витя ему флегматично заметил, что отношение между не меткой Москва и индивидом Москва, а URI http://namespace.ru/cities#Moscow и real 4D Moscow object, и это отношение вообще не в онтологии. Мэтью сказал -- а, так у вас тут genuinely model theory.
То есть в этом месте стыков компьютерных типов и реальных типов нужно как-то гармонизировать две теории: онтологию (что есть в мире) и теорию моделирования (как данные представляют реальный мир). Теорий две, механизмов два, компьютер и оперативная память одна. Вот с этой унификацией все и мучаются, в этом месте у всех дребезг, компьютерные типы данных и традиционные онтологии после этого и не дружат между собой.
-- поскольку нас не волнует decidability, то мы смело можем идти в HOL и модальные логики в плане получения формальной системы (тут нужно сказать, что текущий ISO 15926 ни разу не формальная система, и это источник вечной критики. Хотя у Клювера сотоварищи есть планы его выражения как раз в FOL в конкретном варианте синтаксиса OWL 2 -- но это пока только планы). Но это ведь только про "теоретическую основу", пользователю необязательно это видеть.
-- кроме темплейтов за последний год в тусовке появилось ещё одно средство повышения уровня языка: паттерны. Что это такое, и как с ними обходиться, внятно пока не может сказать никто (несмотря на то, что буквально на днях выходит версия 1.2 нашей софтинки с поддержкой пользовательских паттернов, ибо мы формализовали и реализовали язык описания этих паттернов). Я лично думаю, что привязывать конкретный синтаксис нужно не к темплейтам, а паттернам. Это (надеюсь) будет ещё более человечно (как говорят люди из тусовки, "ближе к инженерам"), чем голые темплейты.
Остальное да, именно так: верифицироваться, отображаться и использоваться в реальных проектах.
Когда я говорю о поддержке системного подхода (понятия "система"), я и имею ввиду именно алфавит и словарь языка для людей. Именно поэтому я ссылаюсь тут не на чисто машинный ISO 15926 как высшее слово разума, а на HQDM, Мэтью Вест его правил именно с интентом сделать понятизацию "системы" более осмысленной для человеков.
Но я в затруднении, что взять за основу для конкретного синтаксиса: то ли диаграммки типа как в книжках BORO, то ли придумать чисто текстовую нотацию. А дальше этот конкретный синтаксис мэппить на онтологические паттерны, которые затем превращаются в темплейты, которые затем поднимаются в граф из сущностей части 2.
Я думаю, что мы подошли к такому месту, что нужен уже хоть какой-то конкретный синтаксис, без которого трудно будет поупражняться в моделировании, а без упражнений будет трудно сформулировать алфавит и словарь системного языка.
Потом вся эта история может повториться в прототипном подходе, но при этом значительная часть собственно "системной" работы и сопутствующей аргументации может быть выполнена на текущем, темплейтно-паттерновом поколении технологий, и перетягивание на новую (или на гибридную, т.е. "добавление" новой) понятийную теорию будет сильно полегче: будет сформулировано (оформлено, документировано) то, что нужно перетягивать.
Reply
Короче говоря, если факты сами себя обрабатывают, то это плохая обработка, а также препятствие для удобной обработки этих фактов чем-либо ещё. Мне кажется, что единственным решением является отсутствие навороченных механизмов вывода в языке. Вывод (даже прототипный) надо оставить имплементациям, и он может влиять на "циферки", но не должен влиять на базовую систему типов.
Reply
Всё одно стоит вопрос про то,
-- как базовую систему типов отображать в конкретном синтаксисе (текстовом? графическом? что брать за основу?), и
-- какие там типы считать базовыми (например, считать нечеловечьи "темпоральные части" и "функциональные физические объекты" из ISO 15926 правильными начальными типами, или "состояния" и "системные компоненты" из HQDM, или тяжело вздохнуть и сразу делать что-то своё на базе моего доклада по понятию "система" и анализа текущих архитектурных языков плюс Моделики).
В любом случае, задача при текущей постановке уже представляется обозримой и обоснованной.
Reply
Сильно разные вещи - система типов (unit, record, tag, ...) и "базовые типы для описания систем" (функциональные физические объекты, etc) как элементы стандартных библиотек.
Диаграммные представления - одну и ту же ситуацию можно представить как state diagram или flowchart. Тоже выбор библиотек.
Reply
Там, конечно, более тонкое отношение между семантикой сериализационного уровня и семантикой видимого людям базового уровня моделирования, тем не менее.
Так что мне нужен текстовый или графический синтаксис для представления "системы", "жизненного цикла" и прочих таких понятий системного языка. Ясно, что unit, record и tag про ЗАПИСЬ представлений о системе, но не про собственно систему (то есть мне нужен уровень, когда я могу уже не столько оговаривать, что я работаю с архитектурным описанием, а не архитектурой, с системным описанием, а не системой, сколько просто опускать слово "описание" без потери понятности и осмысленности).
Reply
Поверх этого может быть реализована библиотека "жизненный цикл". А также, библиотеки "пространство", "время", "единицы измерения", etc.
Reply
Фишка в том, что все эти "число, cardinal_direction, единица измерения" представляют смесь того, как говорят о мире, и объектов самого мира -- то есть смесь системы репрезентации и концептуальной схемы (которая абстрактна и описывает мир, а не способ говорения о мире).
Вот и непонятно без примера, ибо никаких особых принципов по разделению всех этих возможных около-онтологических сущностей на форматы, типы, классы я пока не усматриваю. Мне понятно, что люди привыкли какими-нибудь "питоновскими словарями" выражать объекты реального мира, не задумываясь, что это означает онтологически. Но вот когда говорим о "пространстве", "времени" и "единицах измерения", хотелось бы понимать, чем они принципиально отличаются от подлежащей системы типов (ибо не о разметке же в памяти и не об языковой интерпретации -- то есть свойствах компьютера речь идёт, а о выражении тех или иных свойств мира).
Reply
Базовая система должна равноценно поддерживать нужные типы. В том числе:
1. Vector3d, uint32 и другие типы, значения которых выражены битами/байтами в железе, на котором крутится информационная система.
2. Такие типы как ГородЛондон или ГородОдесса, значения которых представлены в реальном (или возможном) мире, за пределами информационной системы.
Если это разные системы, то как когнитивные затраты со стороны пользователей, так и затрачиваемые машинные ресурсы увеличиваются на порядок.
Reply
Reply
А вот Vector3D и ГородЛондон как раз из этих двух разных подходов: первое "как говорят о мире", а второе -- "про мир", и вот этот стык очень мутный.
Пару дней назад нам написали, что в нашей методологии инженерии референсных данных одновременно Москва и данные (абстрактный объект), и индивид физического объекта, а это противоречиво. Мы подискутировали, в дискуссии поучаствовал и Мэтью Вест -- когда я сказал, что "данные correspond физической Москве, и это обычный вординг iso 15926", он отметил, что "никакого correspond, ибо отношение между меткой Москва и индивидом Москва называется в стандарте representation". Витя ему флегматично заметил, что отношение между не меткой Москва и индивидом Москва, а URI http://namespace.ru/cities#Moscow и real 4D Moscow object, и это отношение вообще не в онтологии. Мэтью сказал -- а, так у вас тут genuinely model theory.
То есть в этом месте стыков компьютерных типов и реальных типов нужно как-то гармонизировать две теории: онтологию (что есть в мире) и теорию моделирования (как данные представляют реальный мир). Теорий две, механизмов два, компьютер и оперативная память одна. Вот с этой унификацией все и мучаются, в этом месте у всех дребезг, компьютерные типы данных и традиционные онтологии после этого и не дружат между собой.
Reply
Reply
Leave a comment