"Р 1323565.1.058-2024. Рекомендации по стандартизации. Национальная система пространственных данных. Разработка системы онтологий. Общие рекомендации"
(утв. и введены в действие Приказом Росстандарта от 25.11.2024 N 1758-ст)

1 РАЗРАБОТАНЫ Публично-правовой компанией "Роскадастр" (ППК "Роскадастр")

2 ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 394 "Географическая информация/геоматика"

3 УТВЕРЖДЕНЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 25 ноября 2024 г. N 1758-ст

4 ВВЕДЕНЫ ВПЕРВЫЕ

Согласно ГОСТ Р 70846.1 одним из основополагающих принципов создания и развития национальной системы пространственных данных (НСПД) является обеспечение онтологического единства данных. В соответствии с данным принципом интеграция информации и данных из различных источников должна проводиться на основе системы онтологий, позволяющей однозначно идентифицировать одни и те же пространственные объекты в контексте различных взглядов (точек зрения экспертов различных предметных областей) в разнородных информационных системах и утверждать применимые именования отношений, связывающие различные сущности вместе, обеспечивая тем самым возможность реализации сложных аналитических операций по извлечению знаний.

Настоящие рекомендации по стандартизации призваны обеспечить разработчиков онтологий правилами и методикой, следование которым позволяет избежать многих ошибок и получить в результате взаимно согласованный набор онтологий, применение которых в рамках НСПД окажется эффективным.

В настоящих рекомендациях устанавливаются требования по построению и содержанию технического задания на выполнение работ по разработке системы онтологий НСПД, а также порядок разработки онтологий, включаемых в состав системы онтологий НСПД, основанные на идеях гибкой методологии разработки. Настоящие рекомендации не ограничивают разработчиков онтологий НСПД в выборе программных и технических средств разработки при условии, что данные средства разработки позволяют реализовать на практике указанный порядок разработки онтологий.

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

Требования к библиотекам шаблонов проектирования онтологий и правила их создания и эксплуатации выходят за рамки настоящих рекомендаций по стандартизации.

В настоящих рекомендациях использованы нормативные ссылки на следующие стандарты:

ГОСТ Р 7.0.91 (ИСО 25964-1:2011) Система стандартов по информации, библиотечному и издательскому делу. Тезаурусы для информационного поиска

ГОСТ Р 52438 Географические информационные системы. Термины и определения

ГОСТ Р 70846.1 Национальная система пространственных данных. Основные положения по стандартизации

ГОСТ Р 70846.2 Национальная система пространственных данных. Термины и определения

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

В настоящих рекомендациях применены термины по ГОСТ Р 70846.2, а также следующие термины с соответствующими определениями:

3.1 адаптация онтошаблона проектирования онтологий (adaptation of ontology design ontopattern): Метод согласования онтошаблона проектирования онтологий и онтологии, в которую данный онтошаблон импортируется, предусматривающий копирование и переименование составляющих онтошаблон проектирования онтологий классов и свойств с целью передачи семантики предметной области или категорий.

3.2 блок знаний (knowledge block): Специфический элемент структуры знаний.

Примечание - Блок знаний может представлять собой сложное понятие или комплекс взаимосвязанных понятий.

3.3 версионирование онтологии (ontology versioning): Процесс создания новой версии онтологии.

3.4 версия онтологии (ontology version): Идентифицируемая редакция онтологии.

Примечание - Мультиязычные онтологии, даже если это не установлено методом, регламентирующим версионирование онтологии, всегда имеют языковые версии, отличающиеся естественным языком, используемым для наименования концептов, записи строковых констант и аннотирования онтологий и их компонентов.

3.5 вопрос компетенции (competency question): Вопрос, на который онтология должна быть способна ответить.

Примечание - Вопросы компетенции выражаются на естественном языке в форме вопросительных предложений.

3.6 выравнивание онтологий (ontology alignment): Процесс выявления и последующего представления в форме аксиом семантической эквивалентности между компонентами разных онтологий.

Примечание - Данный процесс также часто называют отображением одной онтологии в другую(ие).

3.7

3.8 выражение персоны (persona expression): Выражение, используемое для утверждения о персоне.

Примечания - Термин "выражение персоны" вводится для устранения путаницы в тех случаях, когда кто-то один использует "персона" для обозначения модели пользователя, в то время как другой использует "персона" для обозначения лингвистического представления этой модели.

3.9 домен национальной системы пространственных данных (national spatial data system domain): Предметная область (3.43) в пределах всей или тематически определенной совокупности сущностей, представляющих интерес для лиц, участвующих в сфере оборота пространственных данных в Российской Федерации.

3.10 дополнительная онтология национальной системы пространственных данных (additional ontology for national spatial data system): Онтология национальной системы пространственных данных, созданная на базе одной или нескольких опорных онтологий национальной системы пространственных данных и моделирующая концепты и отношения в домене национальной системы пространственных данных, не отнесенные к опорным.

3.11 знание (knowledge): Система концептов, усвоенная человеком в процессе мышления и закрепленная в его памяти.

3.12

3.13

3.14 контекстное утверждение (contextual statement): Ограничение, накладываемое на знания, которые должны присутствовать в ответе онтологии на вопрос компетенции, или утверждение, разъясняющее или уточняющее содержание вопроса компетенции.

3.15

Примечание - Концепты часто также именуются понятиями при разработке онтологий.

3.16 логический шаблон проектирования онтологий (logical ontology design pattern): Шаблон проектирования онтологий, предназначенный для решения проблем ограниченности языка моделирования, используемого для разработки онтологии.

3.17 модуль онтологии (ontology module): Часть онтологии, разработка которой может осуществляться независимо от остальных частей.

Примечание

1 Модули онтологий могут рассматриваться как онтологии особого вида, существование которых невозможно без существования онтологий, модулями которых они являются.

2 Модули онтологии состоят из онтологических моделей классов, отношений и данных.

3.18 мультиязычная онтология (multilanguage ontology): Онтология, содержащая термины и выражения отношений на двух или более языках.

Примечание - Мультиязычные онтологии, содержащие термины и выражения отношений на двух языках, называются двуязычными онтологиями.

3.19 нефункциональное требование (non-functional requirement): Требование, определяющее свойство, которое разрабатываемая онтология должна демонстрировать, или ограничение, которое она должна соблюдать, не относящееся к поведению систем, использующих разрабатываемую онтологию.

3.20

3.21 онтологическая модель данных (ontological data model): Совокупность низкоуровневых компонентов онтологии, моделирующих данные.

3.22 онтологическая модель класса (ontological model of class): Совокупность терминов, выражений класса и аксиом о классе, моделирующих класс.

3.23 онтологическая модель отношения (ontological model of relation): Совокупность выражений отношения, выражений свойства и аксиом о свойстве, моделирующих отношение.

3.24 онтологическая модель партикулярии (ontological model of particular): Совокупность терминов, выражений партикулярии и аксиом о партикулярии, моделирующих партикулярию.

3.25 онтологическая модель типа данных (ontological model of datatype): Совокупность выражений типа данных, выражений диапазона данных и аксиом о типе данных, моделирующих тип данных.

3.26 онтологическая модель типизированного значения (ontological model of typed value): Совокупность онтологической модели типа данных, выражений значения данных и аксиом о свойстве данных, моделирующих значение данных.

3.27

3.28

Примечание - Онтологии высшего уровня иногда называют справочными онтологиями и онтологиями, нейтральными к конкретной предметной области.

3.29 онтология национальной системы пространственных данных (ontology for national spatial data system): Онтология предметной области, термины которой представляют классы или типы и при необходимости конкретные индивиды в домене национальной системы пространственных данных.

3.30

Примечание - Онтологии предметных областей часто называют доменными онтологиями.

3.31 онтология пространственных объектов (ontology of spatial object): Онтология национальной системы пространственных данных, выражающая значимые в рамках национальной системы пространственных данных знания о пространственных объектах.

3.32 онтошаблон проектирования онтологий (ontology design ontopattern): Шаблон проектирования онтологий, представленный в виде онтологии, импортируемой в другую онтологию с последующей процедурой согласования данных онтологий либо используемой как концептуальный ориентир при проектировании блоков знаний в другой онтологии без осуществления импорта.

3.33 опорная онтология национальной системы пространственных данных (core ontology for national spatial data system): Онтология, моделирующая опорные концепты и отношения в домене национальной системы пространственных данных.

3.34 опорный концепт (core concept): Концепт предметной области, входящий в состав минимального набора концептов, посредством которых могут быть определены все или большая часть остальных концептов предметной области.

3.35 опорное отношение (core relation): Отношение в предметной области, связывающее опорные концепты.

3.36

3.37 отраслевой домен национальной системы пространственных данных (industry domain of national spatial data system): Часть домена национальной системы пространственных данных, выделенная на основе отраслевой принадлежности и моделируемая отдельными онтологиями.

Примечание - Создаваемые в рамках отраслевого домена НСПД онтологии именуются отраслевыми онтологиями НСПД.

3.38 персона (persona): Модель пользователя или пользователей, характеризуемых общими потребностями, поведением и целями.

3.39 повторное использование онтологии (ontology reuse): Импорт онтологии или ее части в другую онтологию без изменения значения импортированного содержимого или применение онтошаблона проектирования онтологий.

Примечания - Для обозначения повторного использования онтологии часто также используется термин "переиспользование онтологии".

3.40 пользовательская история (user story): Простое повествование, иллюстрирующее потребность пользователя.

3.41 пользовательская история о нефункциональном требовании (user story about a non-functional requirement): Пользовательская история, выражающая нефункциональное требование.

3.42 пользовательская история о функциональном требовании (user story about a functional requirement): Пользовательская история, выражающая функциональное требование.

3.43

Примечания

1 Одни предметные области могут являться частями других предметных областей.

2 При обозначении конкретных предметных областей допускается вместо термина "предметная область" использовать термин "домен", обозначающий то же понятие.

3.44 проектирование онтологии (ontology design): Процесс определения архитектуры и элементов содержания онтологии.

3.45 пространственный объект (в онтологии) (spatial object): Абстракция объекта реального мира или иного объекта, местоположение которого может быть определено.

Примечания

1 Объект может существовать на уровне типов (классов) или экземпляров классов.

2 Данное определение расширяет понятие пространственного объекта, приведенное в ГОСТ Р 52438, в котором под пространственным объектом понимается исключительно цифровая модель материального или абстрактного объекта реального и виртуального мира с указанием его идентификатора, координатных и атрибутивных данных.

3 При соблюдении требований настоящих рекомендаций пространственные объекты, представляющие собой отдельные сущности в реальном или виртуальном мире, в онтологии всегда будут представляться в виде специально создаваемых уникальных индивидов - абстракций (модельных образов), репрезентующих данные сущности, и, как следствие, отождествляемых с ними. В связи с этим в настоящих рекомендациях не делается различия между данными абстракциями и самими пространственными объектами, на основе которых эти абстракции созданы.

3.46 рефакторинг онтологии (ontology refactoring): Модификация онтологии, направленная на улучшение онтологии при сохранении выражаемой ею семантики.

Примечание - Рефакторинг онтологии чаще всего направлен на повышение понятности и обслуживаемости онтологии.

3.47

3.48 система онтологий национальной системы пространственных данных (ontology system for national spatial data system): Упорядоченная совокупность онтологий национальной системы пространственных данных, а также при необходимости онтологий высшего уровня, представляющих значимые для домена национальной системы пространственных данных категории.

Примечание - Система онтологий национальной системы пространственных данных может рассматриваться как онтология особого вида, содержащая в качестве компонентов отдельные онтологии, входящие в систему.

3.49 специализация онтошаблона проектирования онтологий (ontology design pattern specialization): Метод согласования онтошаблона проектирования онтологий и онтологии, в которую данный онтошаблон импортируется, при котором в онтологии для классов и свойств онтошаблона проектирования онтологий происходит создание подклассов и подсвойств, выражающих семантику предметной области или категорий.

3.50 список пользовательских историй (user story list): Документ, включающий в себя перечень пользовательских историй, иллюстрирующих взаимосвязанный комплекс потребностей пользователей, смоделированных персонами.

3.51 структурный шаблон проектирования онтологий (structural ontology design pattern): Шаблон проектирования онтологий, предназначенный для решения проблем, возникающих при формировании структуры онтологии.

Примечание - Структурные шаблоны проектирования онтологий могут быть одного из двух видов: логические шаблоны проектирования онтологий и архитектурные шаблоны проектирования онтологий.

3.52

3.53

3.54 требование к умозаключениям (reasoning requirements): Требование к логическому выводу знаний из онтологии путем умозаключений при ответе на вопрос компетенции.

3.55

Примечание - Функциональные требования к разрабатываемой онтологии формулируются в виде потребностей в знаниях, удовлетворяемых при использовании онтологии, или ожиданий в получении знаний в результате использования онтологии, которые являются обязательными.

3.56 шаблон проектирования онтологий (ontology design pattern): Описание проблемы, возникающей при проектировании онтологий, и сути ее решения в виде, позволяющем многократное использование этого решения в различных условиях.

3.57

В настоящих рекомендациях применены следующие сокращения:

ВК - вопрос компетенции;

ИСО - Международная организация по стандартизации;

КУ - контекстное утверждение;

ЛШПО - логический шаблон проектирования онтологий;

МЭК - Международная электротехническая комиссия;

ОПО - онтошаблон проектирования онтологий;

СВК - список вопросов компетенции;

СПИ - список пользовательских историй;

СЧ - составная часть;

СШПО - структурный шаблон проектирования онтологий;

ТЗ - техническое задание;

ТУ - требование к умозаключениям;

ШПО - шаблон проектирования онтологий;

IEC - Международная электротехническая комиссия (International Electrotechnical Commission);

OWL - язык сетевых онтологий (Web Ontology Language);

URI - унифицированный идентификатор ресурса (Uniform Resource Identifier);

W3C - Консорциум Всемирной паутины (World Wide Web Consortium).

5.1.1 Для выполнения работ по разработке системы онтологий НСПД рекомендуется применять единую для всех участников разработки информационную систему, включающую, как минимум, средства:

- разработки, модификации, визуализации и хранения онтологий;

- систематизации компонентов онтологий первого и третьего уровней (см. 5.6.3);

- обнаружения и повторного использования компонентов онтологий первого и третьего уровней;

- управления в составе компонентов онтологий первого уровня терминами, выражениями отношений и связями с другими компонентами онтологий первого уровня;

- защиты данных и организации совместной работы участников разработки в соответствии с регламентированными правами доступа;

- управления проектами;

- документирования системы онтологий и ее компонентов третьего уровня.

5.1.2 Разработку системы онтологий НСПД рекомендуется выполнять рабочей группой, участники которой исполняют следующие роли:

- руководитель;

- архитектор онтологий;

- инженер-онтолог;

- специалист в предметной области.

Допускается совмещение ролей, в случае если лицо, назначаемое на выполнение двух или более ролей, обладает требуемой квалификацией.

5.1.3 Разработка системы онтологий НСПД должна осуществляться на основании ТЗ, требования по построению и содержанию которого изложены в 5.2. При выполнении работ по разработке системы онтологий НСПД разработка отдельных онтологий, входящих в состав системы онтологий НСПД, может быть выделена в отдельную (самостоятельную) часть работы. В этом случае разработка онтологий, входящих в состав системы онтологий, должна осуществляться на основании ТЗ на СЧ работы, требования по построению и содержанию которого изложены в 5.3.

5.1.4 При разработке системы онтологий НСПД необходимо стремиться к максимальному использованию накопленного опыта разработки онтологий в виде ШПО, пример описания которого приведен в приложении А.

5.2.1 ТЗ на разработку системы онтологий НСПД должно включать в себя следующие разделы:

- Основание для выполнения работ;

- Сроки выполнения работ;

- Цели разработки, наименование и обозначение результата разработки;

- Требования к источникам знаний и извлекаемых из них знаний;

- Технические требования к результату разработки;

- Этапы выполнения работ;

- Порядок выполнения и приемки этапов работ.

В зависимости от особенностей разрабатываемой системы онтологий НСПД, условий ее применения и эксплуатации допускается вводить в ТЗ другие разделы или исключать разделы, в которых нет необходимости.

5.2.2 В разделе "Цели разработки, наименование и обозначение результата разработки" устанавливают:

- цели разработки системы онтологий НСПД;

- полное наименование разрабатываемой системы онтологий НСПД;

- обозначение разрабатываемой системы онтологий НСПД (если имеется);

- перечень наименований и описаний отраслевых и других доменов НСПД, которые должны быть смоделированы в виде отдельных онтологий или модулей онтологий в системе онтологий НСПД;

- перечень наименований онтологий и систем онтологий, которые разрабатываемая система онтологий НСПД должна заменить, либо факт отсутствия таковых;

- перечень конкретных продуктов или видов продуктов, в которых разрабатываемую систему онтологий НСПД предполагается использовать, с указанием основного назначения и решаемых задач, а также предполагаемых вариантов применения.

5.2.3 В разделе "Требования к источникам знаний и извлекаемых из них знаний" устанавливают:

- перечень обязательных к использованию источников знаний для выполнения работ;

- перечень обязательных для моделирования в системе онтологий НСПД систем концептов, содержащихся в обязательных к использованию источниках знаний и выраженных посредством соответствующих данным концептам терминов в форме повествовательных предложений.

При выборе обязательных к использованию источников знаний для разработки онтологий следует руководствоваться рекомендациями, изложенными в 5.5.

5.2.4 Раздел "Технические требования к результату разработки" может состоять из следующих подразделов:

- Требования к структуре системы в целом;

- Требования назначения;

- Правила именования компонентов;

- Требования к визуальному представлению;

- Требования к формализации знаний;

- Требования к использованию онтошаблонов проектирования онтологий;

- Требования к выравниванию;

- Правила версионирования.

В зависимости от особенностей разрабатываемой системы онтологий НСПД, условий ее применения и эксплуатации допускается вводить в раздел "Технические требования к результату разработки" другие подразделы или исключать подразделы, в которых нет необходимости.

5.2.4.1 В подразделе "Требования к структуре системы в целом" устанавливают:

- перечень онтологий, включаемых в состав системы онтологий НСПД, с указанием их типов согласно типизации онтологий, приведенной в 5.6;

- порядок изменения (при необходимости) утвержденного перечня онтологий, разрабатываемых в составе системы онтологий НСПД;

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

5.2.4.2 В подразделе "Требования назначения" устанавливают перечень функциональных и нефункциональных требований, предъявляемых к каждой разрабатываемой онтологии, в форме СПИ и соответствующего СПИ СВК или указаний на то, что разработка, согласование и утверждение СПИ и/или СВК будет осуществляться в ходе выполнения работ. Во втором случае работы по разработке, согласованию и утверждению СПИ и/или СВК, не указанных в ТЗ, являются обязательными и должны быть запланированы таким образом, чтобы окончание их выполнения предшествовало началу выполнения любых других планируемых в ТЗ работ.

При разработке СПИ и СВК должны быть учтены общие требования к разработке, построению и содержанию СПИ и СВК, изложенные в 5.7.

5.2.4.3 В подразделе "Правила именования компонентов" устанавливают:

- правила именования компонентов нулевого, первого и второго уровней разрабатываемых онтологий с учетом общих правил именования компонентов онтологий, изложенных в 5.8;

- требования по использованию пространств имен.

5.2.4.4 В подразделе "Требования к визуальному представлению" устанавливают требования к графической нотации, используемой для визуального представления разрабатываемой системы онтологий НСПД и ее компонентов в документах и информационных системах.

5.2.4.5 В подразделе "Требования к использованию онтошаблонов проектирования онтологий" устанавливают перечень ОПО, обязательных к использованию в процессе разработки системы онтологий НСПД.

5.2.4.6 В подразделе "Требования к выравниванию" устанавливают:

- перечень наименований онтологий, относительно которых должна быть выравнена разрабатываемая система онтологий НСПД;

- правила выравнивания разрабатываемой системы онтологий НСПД относительно других онтологий.

5.2.4.7 В подразделе "Правила версионирования" устанавливают правила версионирования разрабатываемой системы онтологий НСПД и входящих в ее состав онтологий.

5.2.5 В разделе "Этапы выполнения работ" указывают наименования и последовательность обязательных этапов, а при необходимости - отдельных отчетных подэтапов и конкретный перечень работ, выполняемых на каждом этапе (подэтапе). В этом же разделе указывают сроки выполнения этапов (подэтапов) работ и разработчиков, выполняющих данные этапы.

5.2.6 В разделе "Порядок выполнения и приемки этапов работ" указывают:

- правила и порядок выполнения и приемки этапов работ, а также порядок выполнения и приемки отдельных отчетных подэтапов работ;

- необходимость разработки и контроля промежуточных версий системы онтологий НСПД, их перечень, необходимость разработки для них технической документации, необходимость согласования с заказчиком программ и методик контроля результатов разработки;

- требования к документам разрабатываемой системы онтологий НСПД.

5.3.1 Построение ТЗ на СЧ работ по разработке системы онтологий НСПД должно соответствовать требованиям, установленным в 5.2. Содержание разделов и подразделов ТЗ на СЧ определяет головной разработчик системы онтологий НСПД по согласованию с ее заказчиком.

5.3.2 Требования ТЗ на СЧ работ по разработке системы онтологий НСПД должны предусматривать соблюдение требований общего ТЗ на работы в части, не противоречащей особенностям заданной СЧ работ.

5.3.3 В ТЗ на СЧ работ по разработке системы онтологий НСПД следует изложить специфические требования к разработке отдельной онтологии; общие требования для разработки всех онтологий, входящих в состав разрабатываемой системы онтологий НСПД, следует изложить в виде повторения существенных требований и (или) в виде ссылок на ТЗ на разработку системы онтологий НСПД.

5.4.1 Разработка онтологий, включаемых в состав системы онтологий НСПД, должна осуществляться в следующем порядке:

1) разработка, согласование и утверждение СПИ;

2) разработка, согласование и утверждение СВК;

3) выявление блоков знаний, моделирование которых может быть осуществлено независимо друг от друга;

4) разработка модуля(ей) онтологии;

5) проверка на соответствие установленным требованиям и исправление разработанного(ых) модуля(ей) онтологии;

6) интеграция разработанного(ых) модуля(ей) онтологии с другими модулями той же онтологии;

7) выравнивание и рефакторинг всех созданных модулей онтологии;

8) документирование версии онтологии;

9) приемочный контроль результатов разработки онтологии.

5.4.2 Разработка онтологии должна начинаться с разработки СПИ и/или СВК, если они не были изложены в составе ТЗ на разработку системы онтологий.

Разработанные онтологии СПИ и СВК подвергаются процедуре согласования, целью которой является достижение соглашения между заказчиком и разработчиком системы онтологий НСПД о том, что СПИ соответствует указанным в ТЗ целям разработки, а СВК необходим и достаточен для согласованного СПИ.

5.4.3 Разработка модуля(ей) онтологии должна начинаться с поиска существующих онтологий, которые можно повторно использовать, а также СШПО и ЛШПО, которые могут быть использованы для моделирования ответов на содержащиеся в СВК. При поиске подходящих СШПО и ЛШПО следует обращать внимание на ВК, которые могут сопровождать СШПО и ЛШПО. Данные ВК должны быть подвергнуты анализу на предмет соответствия ВК, сформулированным при разработке модуля, учитывая возможные различия в уровнях абстракции СШПО (ЛШПО) и разрабатываемой онтологии. Результатом анализа должен стать ответ на вопрос, подходит ли анализируемый СШПО или ЛШПО для повторного использования в разрабатываемой онтологии и если подходит, то в каком качестве - как концептуальный ориентир или импортируемый фрагмент онтологии.

Примечание - Обычно для моделирования одной проблемной ситуации (блока знаний) подходящими оказываются несколько различных СШПО или ЛШПО. В таких случаях необходимо тщательно изучить альтернативные ШПО, оценить последствия их применения и наконец найти решение (если таковое имеется), которое наилучшим образом будет соответствовать сформулированным требованиям.

5.4.4 После того как СШПО и ЛШПО выбраны, они должны быть применены. Под применением выбранных СШПО и ЛШПО понимается их использование как концептуальных ориентиров в процессе создания модуля(ей) онтологии либо импортирование ОПО, соответствующих выбранным СШПО и ЛШПО, и согласование импортированных ОПО с разрабатываемым(и) модулем(ями) онтологии посредством специализации или адаптации ОПО.

5.4.5 После того как модуль онтологии разработан, его следует проверить на соответствие всем требованиям, сформулированным в виде ВК. Проверку модуля онтологии рекомендуется выполнять путем добавления в него тестовых экземпляров классов, а затем написания и выполнения запросов, соответствующих ВК. Проверка считается успешно пройденной, если полученные в ответ на запросы экземпляры не отличаются от ожидаемых экземпляров.

Примечания

1 Проверка разработанного модуля на предмет соответствия ТУ осуществляется таким же образом, как и на предмет соответствия ВК. При этом особое внимание при проверке данного вида следует обращать на неожиданные ответы. Именно они, как правило, указывают на проблему в разрабатываемом модуле онтологии.

2 Проверка разработанного модуля на предмет соответствия КУ наиболее сложная. Для ее обеспечения рекомендуется в КУ включать объяснения целей, которые, как правило, и могут быть проверены.

5.4.6 Если к модулю онтологии или всей онтологии были предъявлены нефункциональные требования, они так же, как и функциональные требования, должны быть проверены на этапе проверки на соответствие установленным требованиям и исправления разработанного(ых) модуля(ей) онтологии.

5.4.7 В случае, если в процессе проверки разработанного(ых) модуля(ей) онтологии обнаруживаются ошибки, должны быть проведены работы по исправлению обнаруженных ошибок, после чего разрабатываемый(е) модуль(и) онтологии должен(ны) быть вновь проверен(ы).

5.4.8 В случае, если разрабатываемая онтология состоит из более чем одного модуля, после разработки второго и последующих модулей требуется осуществить их интеграцию с уже разработанными модулями онтологии.

5.4.9 В процессе интеграции разработанного модуля онтологии с другими модулями той же онтологии необходимо решить задачу обеспечения семантического единства и непротиворечивости во всех участвующих в интеграции модулях онтологии. Решение данной задачи осуществляется экспертным методом.

5.4.10 Если в процессе интеграции разработанного(ых) модуля(ей) с другими модулями той же онтологии потребовалась модификация онтологии, которая могла изменить семантику, выражаемую интегрируемым(ми) модулем(ями) и/или модулями, с которыми происходит интеграция, проверка изменившихся модулей онтологии должна быть повторена.

5.4.11 На этапе выравнивания и рефакторинга всех созданных модулей онтологии должны быть решены следующие задачи:

- обеспечено выравнивание разрабатываемой онтологии с другими онтологиями, в том числе и онтологиями НСПД, если это не было сделано ранее, но было предусмотрено ТЗ на разработку системы онтологий НСПД;

- проведен рефакторинг онтологии.

5.4.12 В документации к разработанной версии онтологии должно быть понятно изложено, какие отличия имеет новая версия онтологии по сравнению с предыдущей.

5.4.13 На заключительном этапе разработки онтологии проводится приемочный контроль результатов разработки онтологии, в процессе которого осуществляется оценка разработанной онтологии и сопровождающей ее документации на предмет соответствия заданным требованиям и принятие решения о приемке онтологии либо необходимости возврата на доработку для устранения выявленных несоответствий и исправления ошибок.

5.5.1 При выборе источников знаний для разработки онтологий следует руководствоваться следующими принципами:

- чем выше степень структуризации знаний в источнике информации, тем более высока его потенциальная значимость для разработки онтологий;

- наиболее предпочтительными кандидатами на роль источников знаний при разработке онтологий являются источники знаний, содержащие согласованные точки зрения на моделируемую предметную область или категории;

- каждый потенциальный источник знаний до использования в разработке онтологии должен быть проверен на предмет соответствия содержащихся в нем сведений законодательству и интересам Российской Федерации, а также принципам создания и развития НСПД, приведенным в ГОСТ Р 70846.1.

5.5.2 Выбор источника знаний для разработки онтологий рекомендуется осуществлять путем комплексного анализа следующих фактических данных:

- даты последнего обновления источника знаний;

- юридических и технических ограничений на использование источника знаний;

- естественных и искусственных языков, использованных для записи выражений в источнике знаний;

- перечня источников знаний, с которыми данный источник знаний согласован, и использованных для этого способов согласования.

5.6.1 Онтологии, включаемые в состав системы онтологий НСПД, рекомендуется группировать по предмету концептуализации следующим образом:

а) онтологии, нейтральные к НСПД;

б) онтологии НСПД.

Примечание - Данная типизация не предполагает возможности отнесения конкретной онтологии одновременно к двум типам.

Онтологии НСПД рекомендуется группировать по принадлежности содержащихся в них концептов множеству опорных концептов следующим образом:

а) опорные онтологии НСПД;

б) дополнительные онтологии НСПД.

5.6.2 В систему онтологий НСПД не следует включать две или более нейтральные к НСПД онтологии, содержащие классы, концептуализирующие одни и те же понятия. При этом допускается расширить включаемую в систему онтологий НСПД нейтральную к НСПД онтологию за счет добавления в нее классов из других онтологий при соблюдении всех требований, изложенных в настоящих рекомендациях.

5.6.3 При разработке системы онтологий НСПД рекомендуется применять классификацию компонентов онтологий на четыре классификационные ступени (уровня):

- к компонентам нулевого уровня помимо терминов, выражений отношений и аксиом отнесены также выражения свойств, классов и партикулярий (индивидов), представляющие собой записанные на естественном языке определения соответственно отношений, общих и отдельных сущностей;

- к компонентам первого уровня отнесены онтологические модели отношений, классов и данных;

- к компонентам второго уровня отнесены модули онтологии;

- к компонентам третьего уровня отнесены отдельные онтологии (данный уровень имеется только у систем онтологий).

Онтологические модели данных рекомендуется подразделять на онтологические модели партикулярий (индивидов) и онтологические модели типизированных значений.

5.7.1 СПИ должен включать в себя нумерованный перечень пользовательских историй, а также при необходимости раздел "Обозначения и сокращения в списке пользовательских историй".

Перечень пользовательских историй должен включать в себя пользовательские истории следующих типов: пользовательские истории о функциональных требованиях и пользовательские истории о нефункциональных требованиях.

5.7.2 Выражение персоны, включаемое в пользовательскую историю, должно содержать идентификационную информацию, позволяющую отграничить данную персону от других персон.

5.7.3 Рекомендуется включать в выражения персон каждой пользовательской истории следующую информацию:

- род занятий пользователя;

- описание среды пользователя онтологии, для которого создана соответствующая модель (персона);

- роль пользователя онтологии, для которого создана соответствующая модель (персона), действующего в определенной среде в определенное время.

Допускается вводить сокращения и обозначения выражений персон и использовать их в пользовательских историях. В этом случае соответствия между выражениями персон и их сокращениями и обозначениями должны быть представлены в разделе СПИ "Обозначения и сокращения в списке пользовательских историй", следующим после перечня пользовательских историй СПИ.

5.7.4 Выражение средства в пользовательской истории о функциональном требовании должно содержать глагол, выражающий запрос информации.

5.7.5 Персона, указываемая в пользовательской истории, должна являться моделью каждого пользователя, для которого выраженная в пользовательской истории потребность должна быть удовлетворена.

5.7.6 Оценку качества СПИ рекомендуется проводить на основании критериев и с использованием последовательности операций, изложенных в приложении Б.

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

В случае если качество СПИ оказывается низким, должны быть внесены изменения в СПИ, после чего измененный СПИ вновь подвергнут процедуре оценки.

5.7.7 Пользовательские истории в СПИ должны быть ранжированы по степени значимости для заказчика системы онтологий НСПД. Полученный в результате ранжирования ранг каждой пользовательской истории должен быть указан в круглых скобках после соответствующей пользовательской истории.

5.7.8 СВК должен включать в себя перечень ВК, которые при необходимости могут сопровождаться КУ и ТУ, уточняющими и разъясняющими содержание ВК. КУ и ТУ при наличии излагаются ниже соответствующего ВК в форме отдельного абзаца, в конце которого добавляется "(КУ)" и "(ТУ)" соответственно.

Каждый ВК должен выражать вопрос, ответ на который должен выявлять наличие в онтологии модели знаний, отвечающей потребности, указанной в одной из пользовательских историй СПИ. Информация о данной пользовательской истории указывается в круглых скобках после ВК в форме номера пользовательской истории в соответствующем СПИ.

5.8.1 В онтологиях два неэквивалентных класса не должны обозначаться одним и тем же термином.

Примечание - Данное правило не применяется к разноязычным версиям одной и той же онтологии. Например, допустимо одновременное использование русского термина "карта" для обозначения понятия "карта" и его английского эквивалента "map" в качестве термина для обозначения понятия "отображение" в разноязычных версиях одной и той же онтологии.

5.8.2 Термины онтологий должны быть уникальными удобочитаемыми идентификаторами.

5.8.3 Каждому понятию, моделируемому в онтологии классом, может соответствовать несколько терминов на одном языке, один из которых должен быть помечен как рекомендуемый.

5.8.4 Текст термина должен представлять собой семантически содержательную цепочку слов.

5.8.5 В качестве термина следует выбирать устоявшийся термин, наиболее точно соответствующий понятию.

5.8.6 При именовании онтологических сущностей рекомендуется использовать термины, приведенные в действующих терминологических стандартах и глоссариях, согласованных в рамках технических комитетов по стандартизации.

5.8.7 Термины в онтологиях целесообразно создавать в соответствии с рекомендациями по тезаурусному менеджменту, приведенным в ГОСТ Р 7.0.91.

5.8.8 Для английских терминов необходимо использовать правописание и словарный запас британского английского языка.

5.8.9 В онтологиях классы и партикулярии (индивиды) не должны иметь совпадающие термины.

1 Название на русском языке: "Пространственный охват".

2 Название на английском языке: "Spatial Extent".

3 Авторы: Иванов Иван Иванович.

4 Лицензия: /template/go.php?url=https://creativecommons.org/publicdomain/zero/1.0/deed.ru.

5 Сокращенное обозначение: "ODP_SpatialExtent".

6 Версия: 0.1.

7 URI: /template/go.php?url=https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1.

8 Список пользовательских историй:

1) как пользователь информационного ресурса НСПД я хочу знать, в каких границах располагается пространственный объект;

2) как англоязычный пользователь информационного ресурса НСПД я хочу иметь возможность получать информацию о пространственном охвате на английском языке;

3) как пользователь информационного ресурса НСПД я хочу знать, в какой системе координат задан пространственный охват пространственного объекта.

9 Список вопросов компетенций:

1) какие значения координат имеют точки границы пространственного объекта? (1)

2) с помощью каких английских терминов и выражений отношений может быть описан пространственный охват? (2)

3) какую систему координат имеет пространственный охват для заданного пространственного объекта? (3)

10 Аннотация: ШПО описывает пространственный охват объекта цепочечно-узловой структурой, допуская, что в узлах данной структуры могут находиться объекты любой пространственной локализации (точечные, линейные или площадные). Точное описание местоположения узлов пространственной структуры, описывающей пространственный охват, достигается за счет определения значения координат ассоциированного с каждым узлом точечного пространственного объекта.

11 Область применения: данный ШПО предназначен для моделирования пространственного охвата объектов, положение которых в пространстве определяется посредством координатного описания.

12 Связь с другими ШПО: данный ШПО содержит адаптацию ШПО "Последовательность".

13 Графическая визуализация:

Пояснения <1>: графическая визуализация создана с использованием следующих условных обозначений:

--------------------------------

<1> Данная информация может быть изложена отдельно от описания ШПО. В этом случае на месте данной информации приводится ссылка на источник информации, где это описание приводится.

- заполненный круг: класс, не подвергаемый специализации или адаптации;

- заполненный квадрат: класс, подвергаемый специализации или адаптации;

- стрелка, соединяющая заполненные круги и квадраты между собой: свойство объекта;

- стрелка, соединяющая заполненный круг с кругом, внутри которого указано число 10: свойство данных.

14 ОПО <2>:

--------------------------------

<2> В данном примере текст ОПО представлен в формате OWL 2 посредством синтаксиса RDF/XML, описанного в рекомендации W3C [2].

Б.1 При оценке качества пользовательских историй применяют критерии качества, объединенные в три группы (см. таблицу Б.1):

- синтаксические критерии качества, характеризующие только структуру текстов пользовательских историй без учета их значений;

- семантические критерии качества, оценивающие значения текстов пользовательских историй или отдельных их частей;

- прагматические критерии качества, учитывающие субъективную интерпретацию текстов пользовательских историй аудиторией.

Допускается вводить дополнительные критерии качества в каждую группу.

Б.2 Оценка качества СПИ состоит из трех операций:

1) оценка качества каждой пользовательской истории;

2) оценка качества каждого множества пользовательских историй;

3) итоговая оценка качества СПИ.

Б.3 Оценка качества каждой пользовательской истории представляет собой совокупность операций, включающих:

1) определение значений критериев качества по логической шкале: если пользовательская история удовлетворяет критерию, ей присваивается значение один, в противном случае - ноль;

2) суммирование всех значений критериев качества;

3) сравнение полученной суммы с количеством применимых для пользовательских историй данного типа критериев качества (N): если сумма значений всех применимых критериев качества равна N, пользовательская история оценивается как высокого качества, в противном случае - как низкого качества.

Б.4 Оценка качества множеств пользовательских историй представляет собой последовательность операций:

1) определение значений критериев качества по логической шкале: если множество пользовательских историй удовлетворяет критерию, ему присваивается значение один, в противном случае - ноль;

2) суммирование всех значений критериев качества;

3) сравнение полученной суммы с количеством применимых для множества пользовательских историй данного типа критериев качества (N): если сумма значений всех применимых критериев качества равна N, множество пользовательских историй оценивается как высокого качества, в противном случае - как низкого качества.

Б.5 Итоговая оценка качества пользовательских историй состоит в присваивании всему набору пользовательских историй значения высокого качества, если каждая пользовательская история и набор пользовательских историй были оценены как высокого качества, и низкого качества в противном случае.