Мета 2
Когда-то у ailev в http://ailev.livejournal.com/1053878.html рассматривалась "классификация мета" из дискуссий по MOF (слайд 8 http://jtc1sc32.org/doc/N1751-1800/32N1764-WG2-Tutorial-OnMOF-forSC32.ppt). В том контексте термин "мета" использовали как обобщение абстрактных логических связей, используемых при описании метамоделей.
Выделены следующие разновидности:
1. Type -(instantiation)- Instances
2. Type -(grouping)- Sub Type
3. Description -(describe)- Anything
4. Template -(apply)- Realization
5. Base Model -(base-variant)- Customized
6. Abstract Syntax -(expression)- Expression
Термины выглядят достаточно общими (абстрактными), но на практике оказывается, что всё зависит от реализаций. Каким бы общим не было описание отношения между Type и Instance (или Type и Value) - найдётся множество систем типов, для которых это описание будет ошибочным. С разных точек зрения Type может оказаться Template, а Template оказаться Base Model. А вопросы модальностей - что мы описываем, какие качества и/или требования? - никак не отражены для Description.
На мой взгляд, работающее разделение на такие "мета" может быть проведено только в случае:
1. Заранее выбранной системы типов.
2. Заранее выбранного фреймворка на её основе.
3. Чёткого определения темпоральных и иных модальных аспектов в этом фреймворке.
Очень велика разница между архивным поведением "ModelA была создана на основе ModelB version 15" и активным поведением "ModelA создана на основе ModelB и синхронизируется с её описанием по правилам RulesC (которые могут быть как кодом, так и регламентами организации)".
В свою очередь, вышеуказанная шестёрка (как и другие перечисления из/по-ссылкам-из http://ailev.livejournal.com/1053878.html) хорошо отражает набор смыслов, которые _необходимо_ уметь выражать и отражать в соответствующих системах/фреймворках.
Выделены следующие разновидности:
1. Type -(instantiation)- Instances
2. Type -(grouping)- Sub Type
3. Description -(describe)- Anything
4. Template -(apply)- Realization
5. Base Model -(base-variant)- Customized
6. Abstract Syntax -(expression)- Expression
Термины выглядят достаточно общими (абстрактными), но на практике оказывается, что всё зависит от реализаций. Каким бы общим не было описание отношения между Type и Instance (или Type и Value) - найдётся множество систем типов, для которых это описание будет ошибочным. С разных точек зрения Type может оказаться Template, а Template оказаться Base Model. А вопросы модальностей - что мы описываем, какие качества и/или требования? - никак не отражены для Description.
На мой взгляд, работающее разделение на такие "мета" может быть проведено только в случае:
1. Заранее выбранной системы типов.
2. Заранее выбранного фреймворка на её основе.
3. Чёткого определения темпоральных и иных модальных аспектов в этом фреймворке.
Очень велика разница между архивным поведением "ModelA была создана на основе ModelB version 15" и активным поведением "ModelA создана на основе ModelB и синхронизируется с её описанием по правилам RulesC (которые могут быть как кодом, так и регламентами организации)".
В свою очередь, вышеуказанная шестёрка (как и другие перечисления из/по-ссылкам-из http://ailev.livejournal.com/1053878.html) хорошо отражает набор смыслов, которые _необходимо_ уметь выражать и отражать в соответствующих системах/фреймворках.