> Перевод даётся для удобства чтения. Нормативным является английский оригинал. # Соглашения об именовании **Спецификация Мета-Вселенной** **Идентификатор документа:** MU-V2-ARCH-003 **Название:** Стандарт архитектуры мета-моделей - соглашения об именовании **Класс документа:** нормативный **Версия:** 2.0 (черновик) **Статус:** рабочий черновик **Нормативные ссылки:** Конституция Мета-Вселенной (MUC), MMAS-Core **Информативные ссылки:** Versioning, Протокол федерации Мета-Вселенной (MUFP) **Копирайт:** © Orkestron.AI **Лицензия:** Apache-2.0 --- # 1. Назначение Этот документ определяет правила именования, принятые во всей экосистеме Мета-Вселенной. Единообразное именование улучшает находимость, семантическую совместимость, федерацию, автоматизацию и долгосрочную поддерживаемость. --- # 2. Область применения Эти правила применяются к: - стандартам Мета-Вселенной; - мета-моделям; - бандлам; - слоям; - объектам; - свойствам; - связям; - событиям; - контрактам; - профилям проекций; - пространствам имён. Реализации МОГУТ вводить дополнительные локальные соглашения при условии, что те остаются совместимыми с настоящей спецификацией. --- # 3. Принципы именования Имена ОБЯЗАНЫ быть: - однозначными; - стабильными; - читаемыми человеком; - читаемыми машиной; - независимыми от технологии; - семантически осмысленными. Имена ОБЯЗАНЫ описывать понятия, а не детали реализации. --- # 4. Канонический язык Английский ОБЯЗАН быть каноническим языком для всех нормативных имён. Локализованные подписи МОГУТ предоставляться как метаданные. Канонические идентификаторы ОБЯЗАНЫ оставаться независимыми от языка. --- # 5. Идентификатор и отображаемое имя Каждый значимый артефакт СЛЕДУЕТ различать по двум именам: - Идентификатор (стабильный) - Отображаемое имя (удобное человеку) Пример: Идентификатор: employee.performance-review Отображаемое имя: Employee Performance Review Отображаемые имена МОГУТ меняться. Идентификаторам СЛЕДУЕТ оставаться стабильными. --- # 6. Каноническое семантическое имя (CSN) Различие между идентификатором и отображаемым именем обобщается для каждого публичного понятия в **каноническое семантическое имя (Canonical Semantic Name, CSN)**. Каждое публичное понятие ОБЯЗАНО иметь оба имени: - **человеческое / отображаемое имя** - локализованное, удобное человеку, свободно изменяемое (например, "Salary Agreement"); - неизменяемое **каноническое семантическое имя (CSN)** - стабильный, независимый от технологии идентификатор смысла (например, `employee.compensation.salaryAgreement`). Пример: ```text Display Name : Salary Agreement CSN : employee.compensation.salaryAgreement ``` CSN аналогичен полному имени класса или URI в RDF, но он намеренно **независим от технологии**: он не привязан ни к языку программирования, ни к сериализации, ни к транспорту. Он выражает положение понятия в его семантической иерархии и ничего сверх того. Правила: - Каждое публичное понятие ОБЯЗАНО иметь ровно один CSN. - CSN ОБЯЗАН быть неизменяемым после публикации; переименование понятия ОБЯЗАНО трактоваться как семантическое изменение по правилам документа [Versioning](Versioning.md) и ОБЯЗАНО порождать новый CSN, а не молчаливую перезапись существующего. - Все **взаимодействия в федерации ОБЯЗАНЫ обмениваться именно CSN**. Протокол федерации Мета-Вселенной (MUFP) передаёт CSN; он НЕ ДОЛЖЕН опираться на отображаемые имена как на идентичность. - Пользовательским интерфейсам СЛЕДУЕТ показывать локализованное отображаемое имя, разрешая его в лежащий за ним CSN. - Отображаемые имена МОГУТ различаться по языкам, контекстам и представлениям; CSN ОБЯЗАН оставаться тем же. Чтобы предотвратить столкновение имён в федерации, CSN СЛЕДУЕТ сопровождать [семантическим отпечатком](Versioning.md) той версии, в которой понятие определено. Вместе они дают полное указание: CSN отвечает на вопрос *какое это понятие*, а отпечаток - *какой это смысл*, так что две вселенные, использующие один и тот же CSN, могут проверить, действительно ли они сходятся в его семантике, прежде чем на неё полагаться. --- # 6a. Грамматика CSN и схема идентификаторов Чтобы CSN и идентификаторы можно было проверять машинно, этот раздел задаёт их формальную грамматику. **Каноническое семантическое имя** ОБЯЗАНО соответствовать следующей записи ABNF (RFC 5234): ```abnf CSN = segment *("." segment) segment = lower *(ALPHA / DIGIT) lower = %x61-7A ; a-z (a segment SHALL start lowercase) ALPHA = %x41-5A / %x61-7A DIGIT = %x30-39 ``` Первый `segment` - это **пространство имён**; остальные сегменты именуют понятие внутри него (например, `employee.compensation.salaryAgreement` - пространство имён `employee`). Эта грамматика служит нормативным источником для шаблона `csn` в [`schemas/common.schema.json`](../schemas/common.schema.json) и проверяется правилом `V2-03` из документа [Validation](Validation.md). **Идентификатор** (значение `id` объекта, связи, события, контракта или проекции, а также значение локальной идентичности) непрозрачен и ОБЯЗАН быть стабильным на всё время жизни того, что он именует. Реализация ОБЯЗАНА принять одну из следующих схем идентификаторов и объявить её, чтобы потребители могли её разрешить: | Схема | Форма | Пример | |--------|------|---------| | `uuid` | UUID | `9d3f2c1a-...` | | `uri` | абсолютный URI | `https://acme.example/person/12345` | | `urn` | URN | `urn:mu:person:9d3f2c1a` | | `qname` | `scheme:value` внутри Вселенной | `employee:12345` | Идентификаторы ОБЯЗАНЫ сравниваться как точные последовательности байтов; они НЕ ДОЛЖНЫ приводиться к одному регистру или нормализоваться. [Каноническая идентичность](../04-core-concepts/Identity.md) связывает схему со значением (`{ "scheme": "urn", "value": "urn:mu:person:9d3f2c1a" }`). Новые схемы МОГУТ регистрироваться, не ломая существующие идентификаторы. --- # 7. Соглашение о пространствах имён Каждое публичное понятие ОБЯЗАНО принадлежать пространству имён. Рекомендуемый формат: namespace:Concept Примеры: employee:Skill organization:Department product:Capability schema:Person fhir:Patient Пространства имён ОБЯЗАНЫ быть глобально уникальными в пределах своей семантической области. --- # 8. Именование мета-моделей Мета-моделям СЛЕДУЕТ давать описательные имена. Рекомендуемые примеры: Employee Meta-Model Product Landscape Meta-Model Enterprise Landscape Meta-Model Избегайте имён, привязанных к реализации. --- # 9. Именование бандлов Именам бандлов СЛЕДУЕТ быть существительными, обозначающими семантические домены. Примеры: Identity Knowledge Governance Runtime History Security --- # 10. Именование слоёв Слой ОБЯЗАН представлять одну целостную семантическую тему. Именам слоёв СЛЕДУЕТ: - использовать существительные в единственном числе; - избегать сокращений; - избегать названий технологий. Примеры: Employment History Projects Compensation Competencies --- # 11. Именование объектов Именам объектов СЛЕДУЕТ: - использовать существительные в единственном числе; - обозначать реальные или мыслимые сущности; - избегать терминологии реализации. Предпочтительно: Employee Project Skill Избегать: EmployeeTable ProjectDTO SkillRecord --- # 12. Именование свойств Именам свойств СЛЕДУЕТ: - описывать факты; - использовать lowerCamelCase; - избегать префиксов; - избегать суффиксов из реализации. Предпочтительно: firstName createdAt currentPosition Избегать: emp_name fld1 col_employee --- # 13. Именование связей Именам связей СЛЕДУЕТ описывать семантический смысл. Примеры: worksFor reportsTo owns dependsOn assignedTo Общих имён вроде "link" или "relation" СЛЕДУЕТ избегать. --- # 14. Именование событий Событиям СЛЕДУЕТ описывать свершившиеся факты. Рекомендуемый шаблон: Примеры: EmployeeCreated ContractSigned ProjectArchived Избегайте имён в повелительном наклонении. --- # 15. Именование контрактов Контрактам СЛЕДУЕТ описывать деловое или семантическое назначение. Примеры: Employment Contract Knowledge Disclosure Contract Federation Agreement Избегайте имён, ориентированных на реализацию. --- # 16. Именование файлов Документам спецификации СЛЕДУЕТ использовать форму: Title-Case-With-Hyphens.md Примеры: Meta-Universe-Constitution.md Federation-Contracts.md Identity-Binding.md Файлам-примерам СЛЕДУЕТ включать суффикс: .example.yaml --- # 17. Зарезервированные термины Следующие термины зарезервированы семейством стандартов Мета-Вселенной: Universe Dimension Namespace Meta-Model Bundle Layer Object Projection Relationship Event Contract Context Identity Эти термины НЕ ДОЛЖНЫ переопределяться с несовместимым смыслом. --- # 18. Импортированные стандарты Импортированные понятия ОБЯЗАНЫ сохранять свои исходные имена везде, где это практично. Локальным расширениям СЛЕДУЕТ расширять импортированные понятия, а не переименовывать их. Пример: schema:Person ↓ employee:Employee --- # 19. Стабильность именования Идентификаторы ОБЯЗАНЫ оставаться стабильными в пределах совместимых версий. Переименование СЛЕДУЕТ трактовать как семантическое изменение. Указания по миграции ОБЯЗАНЫ предоставляться всякий раз, когда идентификаторы меняются. --- # 20. Направления развития Каноническое семантическое имя закладывает стабильный, независимый от технологии слой идентичности, который дальнейшая работа может развернуть в **семантическое руководство по стилю**: сопутствующий стандарт, задающий грамматику сегментов CSN, правила регистра и множественного числа, рекомендуемую глубину иерархии и алгоритм разрешения, по которому локализованное отображаемое имя отображается в CSN на разных языках. Такое руководство описало бы также общефедеративную службу разрешения CSN, чтобы любая вселенная могла разыменовать CSN в определяющую его версию и [семантический отпечаток](Versioning.md), замкнув круг между именованием и смыслом. --- # Заключение Единообразное именование - предпосылка семантической совместимости. Цель этих соглашений не в стилистическом единообразии как таковом, а в создании стабильных, понятных во всём мире семантических моделей, которые способны развиваться, объединяться в федерации и надёжно истолковываться как людьми, так и системами ИИ.