Р 1323565.1.058-2024. Рекомендации по стандартизации. Национальная система пространственных данных. Разработка системы онтологий. Общие рекомендации
(утв. и введены в действие Приказом Росстандарта от 25.11.2024 № 1758-ст)
Примечание
Документ введен в действие с 01.02.2025.
Утверждены и введены в действие
Приказом Федерального
агентства по техническому
регулированию и метрологии
от 25 ноября 2024 г. № 1758-ст
РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ
НАЦИОНАЛЬНАЯ СИСТЕМА ПРОСТРАНСТВЕННЫХ ДАННЫХ
National spatial data system. Development of ontology
system. General recommendations
1 февраля 2025 года
Предисловие
1 РАЗРАБОТАНЫ Публично-правовой компанией «Роскадастр» (ППК «Роскадастр»)
2 ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 394 «Географическая информация/геоматика»
3 УТВЕРЖДЕНЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 25 ноября 2024 г. № 1758-ст
Правила применения настоящих рекомендаций установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящим рекомендациям публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящих рекомендаций соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)
Введение
Согласно ГОСТ Р 70846.1 одним из основополагающих принципов создания и развития национальной системы пространственных данных (НСПД) является обеспечение онтологического единства данных. В соответствии с данным принципом интеграция информации и данных из различных источников должна проводиться на основе системы онтологий, позволяющей однозначно идентифицировать одни и те же пространственные объекты в контексте различных взглядов (точек зрения экспертов различных предметных областей) в разнородных информационных системах и утверждать применимые именования отношений, связывающие различные сущности вместе, обеспечивая тем самым возможность реализации сложных аналитических операций по извлечению знаний.
Настоящие рекомендации по стандартизации призваны обеспечить разработчиков онтологий правилами и методикой, следование которым позволяет избежать многих ошибок и получить в результате взаимно согласованный набор онтологий, применение которых в рамках НСПД окажется эффективным.
В настоящих рекомендациях устанавливаются требования по построению и содержанию технического задания на выполнение работ по разработке системы онтологий НСПД, а также порядок разработки онтологий, включаемых в состав системы онтологий НСПД, основанные на идеях гибкой методологии разработки. Настоящие рекомендации не ограничивают разработчиков онтологий НСПД в выборе программных и технических средств разработки при условии, что данные средства разработки позволяют реализовать на практике указанный порядок разработки онтологий.
1 Область применения
Настоящие рекомендации устанавливают общие положения организационного и методического характера применительно к разработке системы онтологий, выполняемой в целях обеспечения функционирования и развития НСПД. Настоящие рекомендации могут быть применены на отдельных стадиях разработки системы онтологий НСПД, при этом максимальный эффект от их использования может быть достигнут в случае, когда применение настоящих рекомендаций охватывает весь процесс разработки системы онтологий НСПД — от подготовки технического задания до приемки разработанных онтологий и включения их в систему онтологий НСПД.
Требования к библиотекам шаблонов проектирования онтологий и правила их создания и эксплуатации выходят за рамки настоящих рекомендаций по стандартизации.
2 Нормативные ссылки
В настоящих рекомендациях использованы нормативные ссылки на следующие стандарты:
ГОСТ Р 7.0.91 (ИСО 25964-1:2011) Система стандартов по информации, библиотечному и издательскому делу. Тезаурусы для информационного поиска
ГОСТ Р 52438 Географические информационные системы. Термины и определения
ГОСТ Р 70846.1 Национальная система пространственных данных. Основные положения по стандартизации
ГОСТ Р 70846.2 Национальная система пространственных данных. Термины и определения
Примечание - При пользовании настоящими рекомендациями целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящих рекомендаций в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3 Термины и определения
В настоящих рекомендациях применены термины по ГОСТ Р 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.8 выражение персоны (persona expression): Выражение, используемое для утверждения о персоне.
Примечания - Термин «выражение персоны» вводится для устранения путаницы в тех случаях, когда кто-то один использует «персона» для обозначения модели пользователя, в то время как другой использует «персона» для обозначения лингвистического представления этой модели.
3 Разработчик программного обеспечения.
4 Пользователь сервиса геокодирования адресов.
5 Студент, изучающий геодезию.
3.9 домен национальной системы пространственных данных (national spatial data system domain): Предметная область (3.43) в пределах всей или тематически определенной совокупности сущностей, представляющих интерес для лиц, участвующих в сфере оборота пространственных данных в Российской Федерации.
2 «Метаданные наборов данных».
3 «Представление и запрос пространственных данных».
4 «Домен „Национальная система пространственных данных“ на платформе „ГосТех“.»
3.10 дополнительная онтология национальной системы пространственных данных (additional ontology for national spatial data system): Онтология национальной системы пространственных данных, созданная на базе одной или нескольких опорных онтологий национальной системы пространственных данных и моделирующая концепты и отношения в домене национальной системы пространственных данных, не отнесенные к опорным.
1 Онтология оценки стоимости недвижимости, дополняющая опорную онтологию кадастра недвижимости.
2 Онтология цифровых топографических карт, дополняющая опорную онтологию картографии.
3.11 знание (knowledge): Система концептов, усвоенная человеком в процессе мышления и закрепленная в его памяти.
| категория (category): Общий класс или тип, который используется во многих различных предметных областях и представлен термином, не относящимся к одной конкретной предметной области. [ГОСТ Р ИСО/МЭК 21838-1-2021, пункт 3.19] |
|---|
3.14 контекстное утверждение (contextual statement): Ограничение, накладываемое на знания, которые должны присутствовать в ответе онтологии на вопрос компетенции, или утверждение, разъясняющее или уточняющее содержание вопроса компетенции.
| концепт (concept): Ментальное представление знания как абстракции существенных характеристик типа сущности или отношения между сущностями. ГОСТ Р 70846.3-2023, [пункт 3.18] |
|---|
Примечание - Концепты часто также именуются понятиями при разработке онтологий.
3.16 логический шаблон проектирования онтологий (logical ontology design pattern): Шаблон проектирования онтологий, предназначенный для решения проблем ограниченности языка моделирования, используемого для разработки онтологии.
3.17 модуль онтологии (ontology module): Часть онтологии, разработка которой может осуществляться независимо от остальных частей.
1 Модули онтологий могут рассматриваться как онтологии особого вида, существование которых невозможно без существования онтологий, модулями которых они являются.
2 Модули онтологии состоят из онтологических моделей классов, отношений и данных.
3.18 мультиязычная онтология (multilanguage ontology): Онтология, содержащая термины и выражения отношений на двух или более языках.
Примечание - Мультиязычные онтологии, содержащие термины и выражения отношений на двух языках, называются двуязычными онтологиями.
3.19 нефункциональное требование (non-functional requirement): Требование, определяющее свойство, которое разрабатываемая онтология должна демонстрировать, или ограничение, которое она должна соблюдать, не относящееся к поведению систем, использующих разрабатываемую онтологию.
1 Онтология кадастра недвижимости должна содержать классы, моделирующие понятия кадастрового участка и кадастровой границы.
2 Имена классов онтологии должны начинаться с прописной буквы.
3 Термины онтологии должны быть представлены на русском и английском языках.
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): Совокупность онтологической модели типа данных, выражений значения данных и аксиом о свойстве данных, моделирующих значение данных.
| онтология высшего уровня (top-level ontology, TLO): Онтология, созданная для представления категорий, которые используются в максимально широком спектре предметных областей. [ГОСТ Р ИСО/МЭК 21838-1-2021, пункт 3.20] |
|---|
Примечание - Онтологии высшего уровня иногда называют справочными онтологиями и онтологиями, нейтральными к конкретной предметной области.
3.29 онтология национальной системы пространственных данных (ontology for national spatial data system): Онтология предметной области, термины которой представляют классы или типы и при необходимости конкретные индивиды в домене национальной системы пространственных данных.
| онтология предметной области (domain ontology): Онтология, термины которой представляют классы или типы и при необходимости конкретные индивиды в некоторой предметной области. [Адаптировано из ГОСТ Р ИСО/МЭК 21838-1-2021, пункт 3.18] |
|---|
Примечание - Онтологии предметных областей часто называют доменными онтологиями.
3.31 онтология пространственных объектов (ontology of spatial object): Онтология национальной системы пространственных данных, выражающая значимые в рамках национальной системы пространственных данных знания о пространственных объектах.
3.32 онтошаблон проектирования онтологий (ontology design ontopattern): Шаблон проектирования онтологий, представленный в виде онтологии, импортируемой в другую онтологию с последующей процедурой согласования данных онтологий либо используемой как концептуальный ориентир при проектировании блоков знаний в другой онтологии без осуществления импорта.
3.33 опорная онтология национальной системы пространственных данных (core ontology for national spatial data system): Онтология, моделирующая опорные концепты и отношения в домене национальной системы пространственных данных.
1 Онтология пространственных объектов.
2 Опорная онтология кадастра недвижимости.
3 Опорная онтология картографии.
3.34 опорный концепт (core concept): Концепт предметной области, входящий в состав минимального набора концептов, посредством которых могут быть определены все или большая часть остальных концептов предметной области.
3.35 опорное отношение (core relation): Отношение в предметной области, связывающее опорные концепты.
| отношение (relation): Способ, которым связаны сущности. [ГОСТ Р ИСО/МЭК 21838-1-2021, пункт 3.4] |
|---|
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): Пользовательская история, выражающая нефункциональное требование.
1 Как архитектор системы онтологий НСПД, в которую онтология кадастра недвижимости должна включаться, я хочу, чтобы понятия кадастрового участка и кадастровой границы моделировались в онтологии кадастра недвижимости классами.
2 Как архитектор системы онтологий НСПД, в которую разрабатываемая онтология должна включаться, я хочу, чтобы имена классов онтологии начинались с прописной буквы.
3 Как англоязычный пользователь онтологии я хочу иметь возможность получать информацию из онтологии на английском языке.
3.42 пользовательская история о функциональном требовании (user story about a functional requirement): Пользовательская история, выражающая функциональное требование.
1 Как инженер-картограф я хочу знать характеристики типов картографических объектов.
2 Как пользователь сервисов НСПД я хочу знать систему классификации (типизации) пространственных объектов.
1 Одни предметные области могут являться частями других предметных областей.
2 При обозначении конкретных предметных областей допускается вместо термина «предметная область» использовать термин «домен», обозначающий то же понятие.
3.44 проектирование онтологии (ontology design): Процесс определения архитектуры и элементов содержания онтологии.
3.45 пространственный объект (в онтологии) (spatial object): Абстракция объекта реального мира или иного объекта, местоположение которого может быть определено.
1 Объект может существовать на уровне типов (классов) или экземпляров классов.
2 Данное определение расширяет понятие пространственного объекта, приведенное в ГОСТ Р 52438, в котором под пространственным объектом понимается исключительно цифровая модель материального или абстрактного объекта реального и виртуального мира с указанием его идентификатора, координатных и атрибутивных данных.
3 При соблюдении требований настоящих рекомендаций пространственные объекты, представляющие собой отдельные сущности в реальном или виртуальном мире, в онтологии всегда будут представляться в виде специально создаваемых уникальных индивидов — абстракций (модельных образов), репрезентующих данные сущности, и, как следствие, отождествляемых с ними. В связи с этим в настоящих рекомендациях не делается различия между данными абстракциями и самими пространственными объектами, на основе которых эти абстракции созданы.
3.46 рефакторинг онтологии (ontology refactoring): Модификация онтологии, направленная на улучшение онтологии при сохранении выражаемой ею семантики.
Примечание - Рефакторинг онтологии чаще всего направлен на повышение понятности и обслуживаемости онтологии.
3.48 система онтологий национальной системы пространственных данных (ontology system for national spatial data system): Упорядоченная совокупность онтологий национальной системы пространственных данных, а также при необходимости онтологий высшего уровня, представляющих значимые для домена национальной системы пространственных данных категории.
Примечание - Система онтологий национальной системы пространственных данных может рассматриваться как онтология особого вида, содержащая в качестве компонентов отдельные онтологии, входящие в систему.
термин (term): Выражение, относящееся к некоторому классу или некоторой партикулярии.
Примечание - Онтология обычно содержит уникальный «рекомендуемый термин» для сущностей в пределах своего охвата. Рекомендуемые термины могут быть дополнены другими терминами, признанными в онтологии их синонимами.
[ГОСТ Р ИСО/МЭК 21838-1-2021, пункт 3.7]
| требование (requirement): Потребность или ожидание, которые установлены, обычно предполагаются или являются обязательными. ГОСТ ISO 9000-2011, [пункт 3.1.2] |
|---|
3.54 требование к умозаключениям (reasoning requirements): Требование к логическому выводу знаний из онтологии путем умозаключений при ответе на вопрос компетенции.
| функциональное требование (functional requirement): Требование, которое определяет функцию, которую система или системный компонент должны быть способны выполнять. [ГОСТ Р ИСО/МЭК 25040-2014, пункт 4.28] |
|---|
Примечание - Функциональные требования к разрабатываемой онтологии формулируются в виде потребностей в знаниях, удовлетворяемых при использовании онтологии, или ожиданий в получении знаний в результате использования онтологии, которые являются обязательными.
1 Онтология картографических объектов должна позволять получать по запросу пользователя для конкретного типа картографических объектов все применимые для него характеристики.
2 Онтология адресации должна позволять получать по запросу пользователя адреса объектов адресации, официально установленных в Российской Федерации.
3.56 шаблон проектирования онтологий (ontology design pattern): Описание проблемы, возникающей при проектировании онтологий, и сути ее решения в виде, позволяющем многократное использование этого решения в различных условиях.
4 Сокращения
В настоящих рекомендациях применены следующие сокращения:
ИСО — Международная организация по стандартизации;
ЛШПО — логический шаблон проектирования онтологий;
МЭК — Международная электротехническая комиссия;
ОПО — онтошаблон проектирования онтологий;
СВК — список вопросов компетенции;
СПИ — список пользовательских историй;
СШПО — структурный шаблон проектирования онтологий;
ТУ — требование к умозаключениям;
ШПО — шаблон проектирования онтологий;
IEC — Международная электротехническая комиссия (International Electrotechnical Commission);
OWL — язык сетевых онтологий (Web Ontology Language);
URI — унифицированный идентификатор ресурса (Uniform Resource Identifier);
W3C — Консорциум Всемирной паутины (World Wide Web Consortium).
5 Рекомендации по разработке системы онтологий НСПД
5.1 Общие положения
5.1.1 Для выполнения работ по разработке системы онтологий НСПД рекомендуется применять единую для всех участников разработки информационную систему, включающую, как минимум, средства:
- разработки, модификации, визуализации и хранения онтологий;
- систематизации компонентов онтологий первого и третьего уровней (см. 5.6.3);
- обнаружения и повторного использования компонентов онтологий первого и третьего уровней;
- управления в составе компонентов онтологий первого уровня терминами, выражениями отношений и связями с другими компонентами онтологий первого уровня;
- защиты данных и организации совместной работы участников разработки в соответствии с регламентированными правами доступа;
- управления проектами;
- документирования системы онтологий и ее компонентов третьего уровня.
Пример - Программное обеспечение для коллективной разработки онтологий и создания прикладных решений на их основе «OSA — Ontology Space Agent».
5.1.2 Разработку системы онтологий НСПД рекомендуется выполнять рабочей группой, участники которой исполняют следующие роли:
Допускается совмещение ролей, в случае если лицо, назначаемое на выполнение двух или более ролей, обладает требуемой квалификацией.
5.1.3 Разработка системы онтологий НСПД должна осуществляться на основании ТЗ, требования по построению и содержанию которого изложены в 5.2. При выполнении работ по разработке системы онтологий НСПД разработка отдельных онтологий, входящих в состав системы онтологий НСПД, может быть выделена в отдельную (самостоятельную) часть работы. В этом случае разработка онтологий, входящих в состав системы онтологий, должна осуществляться на основании ТЗ на СЧ работы, требования по построению и содержанию которого изложены в 5.3.
5.1.4 При разработке системы онтологий НСПД необходимо стремиться к максимальному использованию накопленного опыта разработки онтологий в виде ШПО, пример описания которого приведен в приложении А.
5.2 Требования по построению и содержанию ТЗ на разработку системы онтологий НСПД
5.2.1 ТЗ на разработку системы онтологий НСПД должно включать в себя следующие разделы:
- Основание для выполнения работ;
- Сроки выполнения работ;
- Цели разработки, наименование и обозначение результата разработки;
- Требования к источникам знаний и извлекаемых из них знаний;
- Технические требования к результату разработки;
- Этапы выполнения работ;
- Порядок выполнения и приемки этапов работ.
В зависимости от особенностей разрабатываемой системы онтологий НСПД, условий ее применения и эксплуатации допускается вводить в ТЗ другие разделы или исключать разделы, в которых нет необходимости.
5.2.2 В разделе «Цели разработки, наименование и обозначение результата разработки» устанавливают:
- цели разработки системы онтологий НСПД;
- полное наименование разрабатываемой системы онтологий НСПД;
- обозначение разрабатываемой системы онтологий НСПД (если имеется);
- перечень наименований и описаний отраслевых и других доменов НСПД, которые должны быть смоделированы в виде отдельных онтологий или модулей онтологий в системе онтологий НСПД;
- перечень наименований онтологий и систем онтологий, которые разрабатываемая система онтологий НСПД должна заменить, либо факт отсутствия таковых;
- перечень конкретных продуктов или видов продуктов, в которых разрабатываемую систему онтологий НСПД предполагается использовать, с указанием основного назначения и решаемых задач, а также предполагаемых вариантов применения.
5.2.3 В разделе «Требования к источникам знаний и извлекаемых из них знаний» устанавливают:
- перечень обязательных к использованию источников знаний для выполнения работ;
- перечень обязательных для моделирования в системе онтологий НСПД систем концептов, содержащихся в обязательных к использованию источниках знаний и выраженных посредством соответствующих данным концептам терминов в форме повествовательных предложений.
Пример - «1. Разрабатываемая онтология должна моделировать знания о структуре адреса, сформулированные в ISO 19160-1:2015. 2. Разрабатываемая онтология должна моделировать знания об эталонной модели, выраженные в ИСО 19101-1:2014».
При выборе обязательных к использованию источников знаний для разработки онтологий следует руководствоваться рекомендациями, изложенными в 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 Требования по построению и содержанию ТЗ на СЧ работ по разработке системы онтологий НСПД
5.3.1 Построение ТЗ на СЧ работ по разработке системы онтологий НСПД должно соответствовать требованиям, установленным в 5.2. Содержание разделов и подразделов ТЗ на СЧ определяет головной разработчик системы онтологий НСПД по согласованию с ее заказчиком.
5.3.2 Требования ТЗ на СЧ работ по разработке системы онтологий НСПД должны предусматривать соблюдение требований общего ТЗ на работы в части, не противоречащей особенностям заданной СЧ работ.
5.3.3 В ТЗ на СЧ работ по разработке системы онтологий НСПД следует изложить специфические требования к разработке отдельной онтологии; общие требования для разработки всех онтологий, входящих в состав разрабатываемой системы онтологий НСПД, следует изложить в виде повторения существенных требований и (или) в виде ссылок на ТЗ на разработку системы онтологий НСПД.
5.4 Порядок разработки онтологий, включаемых в состав системы онтологий НСПД
5.4.1 Разработка онтологий, включаемых в состав системы онтологий НСПД, должна осуществляться в следующем порядке:
-
выявление блоков знаний, моделирование которых может быть осуществлено независимо друг от друга;
-
проверка на соответствие установленным требованиям и исправление разработанного(ых) модуля(ей) онтологии;
-
интеграция разработанного(ых) модуля(ей) онтологии с другими модулями той же онтологии;
-
выравнивание и рефакторинг всех созданных модулей онтологии;
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 Рекомендации по выбору источников знаний для разработки онтологий
5.5.1 При выборе источников знаний для разработки онтологий следует руководствоваться следующими принципами:
- чем выше степень структуризации знаний в источнике информации, тем более высока его потенциальная значимость для разработки онтологий;
- наиболее предпочтительными кандидатами на роль источников знаний при разработке онтологий являются источники знаний, содержащие согласованные точки зрения на моделируемую предметную область или категории;
1 Словари и глоссарии, разрабатываемые международными научными организациями.
2 Онтологии, создаваемые международными стандартизующими организациями.
3 Действующие в Российской Федерации нормативные правовые акты органов государственной власти и документы по стандартизации.
- каждый потенциальный источник знаний до использования в разработке онтологии должен быть проверен на предмет соответствия содержащихся в нем сведений законодательству и интересам Российской Федерации, а также принципам создания и развития НСПД, приведенным в ГОСТ Р 70846.1.
5.5.2 Выбор источника знаний для разработки онтологий рекомендуется осуществлять путем комплексного анализа следующих фактических данных:
- даты последнего обновления источника знаний;
- юридических и технических ограничений на использование источника знаний;
- естественных и искусственных языков, использованных для записи выражений в источнике знаний;
- перечня источников знаний, с которыми данный источник знаний согласован, и использованных для этого способов согласования.
5.6 Типы онтологий, включаемых в состав системы онтологий НСПД
5.6.1 Онтологии, включаемые в состав системы онтологий НСПД, рекомендуется группировать по предмету концептуализации следующим образом:
а) онтологии, нейтральные к НСПД;
Примечание - Данная типизация не предполагает возможности отнесения конкретной онтологии одновременно к двум типам.
Онтологии НСПД рекомендуется группировать по принадлежности содержащихся в них концептов множеству опорных концептов следующим образом:
б) дополнительные онтологии НСПД.
5.6.2 В систему онтологий НСПД не следует включать две или более нейтральные к НСПД онтологии, содержащие классы, концептуализирующие одни и те же понятия. При этом допускается расширить включаемую в систему онтологий НСПД нейтральную к НСПД онтологию за счет добавления в нее классов из других онтологий при соблюдении всех требований, изложенных в настоящих рекомендациях.
Пример - Если две нейтральные к НСПД онтологии содержат классы, концептуализирующие понятие «временной интервал», то в систему онтологий НСПД может быть включена только одна из этих двух онтологий.
5.6.3 При разработке системы онтологий НСПД рекомендуется применять классификацию компонентов онтологий на четыре классификационные ступени (уровня):
- к компонентам нулевого уровня помимо терминов, выражений отношений и аксиом отнесены также выражения свойств, классов и партикулярий (индивидов), представляющие собой записанные на естественном языке определения соответственно отношений, общих и отдельных сущностей;
- к компонентам первого уровня отнесены онтологические модели отношений, классов и данных;
- к компонентам второго уровня отнесены модули онтологии;
- к компонентам третьего уровня отнесены отдельные онтологии (данный уровень имеется только у систем онтологий).
Онтологические модели данных рекомендуется подразделять на онтологические модели партикулярий (индивидов) и онтологические модели типизированных значений.
5.7 Общие требования к разработке, построению и содержанию СПИ и СВК
5.7.1 СПИ должен включать в себя нумерованный перечень пользовательских историй, а также при необходимости раздел «Обозначения и сокращения в списке пользовательских историй».
Перечень пользовательских историй должен включать в себя пользовательские истории следующих типов: пользовательские истории о функциональных требованиях и пользовательские истории о нефункциональных требованиях.
5.7.2 Выражение персоны, включаемое в пользовательскую историю, должно содержать идентификационную информацию, позволяющую отграничить данную персону от других персон.
5.7.3 Рекомендуется включать в выражения персон каждой пользовательской истории следующую информацию:
2 Разработчик программного обеспечения.
2 Организация, выступающая в роли поставщика пространственных данных для сервиса НСПД.
- роль пользователя онтологии, для которого создана соответствующая модель (персона), действующего в определенной среде в определенное время.
Допускается вводить сокращения и обозначения выражений персон и использовать их в пользовательских историях. В этом случае соответствия между выражениями персон и их сокращениями и обозначениями должны быть представлены в разделе СПИ «Обозначения и сокращения в списке пользовательских историй», следующим после перечня пользовательских историй СПИ.
5.7.4 Выражение средства в пользовательской истории о функциональном требовании должно содержать глагол, выражающий запрос информации.
Пример - Хочу знать (типы картографических условных знаков).
5.7.5 Персона, указываемая в пользовательской истории, должна являться моделью каждого пользователя, для которого выраженная в пользовательской истории потребность должна быть удовлетворена.
Пример - «Как разработчик цифровых топографических карт я хочу знать типы картографических условных знаков, с помощью которых на картах данного типа показываются объекты местности» (персона, указанная в пользовательской истории, не отражает потребность пользователей цифровых топографических карт).
5.7.6 Оценку качества СПИ рекомендуется проводить на основании критериев и с использованием последовательности операций, изложенных в приложении Б.
Оценку качества пользовательских историй проводят руководители рабочих групп вместе с инженерами-онтологами экспертным методом на базе их опыта и интуиции с привлечением при необходимости программных средств, упрощающих процесс экспертизы.
В случае если качество СПИ оказывается низким, должны быть внесены изменения в СПИ, после чего измененный СПИ вновь подвергнут процедуре оценки.
5.7.7 Пользовательские истории в СПИ должны быть ранжированы по степени значимости для заказчика системы онтологий НСПД. Полученный в результате ранжирования ранг каждой пользовательской истории должен быть указан в круглых скобках после соответствующей пользовательской истории.
5.7.8 СВК должен включать в себя перечень ВК, которые при необходимости могут сопровождаться КУ и ТУ, уточняющими и разъясняющими содержание ВК. КУ и ТУ при наличии излагаются ниже соответствующего ВК в форме отдельного абзаца, в конце которого добавляется «(КУ)» и «(ТУ)» соответственно.
Пример - Пространственные объекты каких типов отображаются на топографических картах заданного масштаба (уровня детализации) (ВК)?
Под отображением пространственных объектов на картах заданного масштаба (уровня детализации) следует понимать моделирование пространственных объектов картографическими объектами с последующей их визуализацией с помощью условных знаков на картах заданного масштаба (уровня детализации) (КУ).
Тип пространственных объектов считается таковым, что его объекты отображаются на карте заданного масштаба (уровня детализации), если для данного типа объектов указан диапазон масштабов карт (уровней детализации), при котором картографические объекты соответствующего типа визуализируются с помощью установленных условных знаков (ТУ).
Каждый ВК должен выражать вопрос, ответ на который должен выявлять наличие в онтологии модели знаний, отвечающей потребности, указанной в одной из пользовательских историй СПИ. Информация о данной пользовательской истории указывается в круглых скобках после ВК в форме номера пользовательской истории в соответствующем СПИ.
5.8 Общие правила именования компонентов онтологий
5.8.1 В онтологиях два неэквивалентных класса не должны обозначаться одним и тем же термином.
Пример - Использование термина «map» для обозначения понятий «карта» и «отображение» не допустимо.
Примечание - Данное правило не применяется к разноязычным версиям одной и той же онтологии. Например, допустимо одновременное использование русского термина «карта» для обозначения понятия «карта» и его английского эквивалента «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 Лицензия: https://creativecommons.org/publicdomain/zero/1.0/deed.ru.
5 Сокращенное обозначение: «ODP_SpatialExtent».
7 URI: https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1.
8 Список пользовательских историй:
-
как пользователь информационного ресурса НСПД я хочу знать, в каких границах располагается пространственный объект;
-
как англоязычный пользователь информационного ресурса НСПД я хочу иметь возможность получать информацию о пространственном охвате на английском языке;
-
как пользователь информационного ресурса НСПД я хочу знать, в какой системе координат задан пространственный охват пространственного объекта.
9 Список вопросов компетенций:
-
какие значения координат имеют точки границы пространственного объекта? (1)
-
с помощью каких английских терминов и выражений отношений может быть описан пространственный охват? (2)
-
какую систему координат имеет пространственный охват для заданного пространственного объекта? (3)
10 Аннотация: ШПО описывает пространственный охват объекта цепочечно-узловой структурой, допуская, что в узлах данной структуры могут находиться объекты любой пространственной локализации (точечные, линейные или площадные). Точное описание местоположения узлов пространственной структуры, описывающей пространственный охват, достигается за счет определения значения координат ассоциированного с каждым узлом точечного пространственного объекта.
11 Область применения: данный ШПО предназначен для моделирования пространственного охвата объектов, положение которых в пространстве определяется посредством координатного описания.
12 Связь с другими ШПО: данный ШПО содержит адаптацию ШПО «Последовательность».
Пояснения <1>: графическая визуализация создана с использованием следующих условных обозначений:
<1> Данная информация может быть изложена отдельно от описания ШПО. В этом случае на месте данной информации приводится ссылка на источник информации, где это описание приводится.
- заполненный квадрат: класс, подвергаемый специализации или адаптации;
- стрелка, соединяющая заполненные круги и квадраты между собой: свойство объекта;
- стрелка, соединяющая заполненный круг с кругом, внутри которого указано число 10: свойство данных.
14 ОПО <2>:
<2> В данном примере текст ОПО представлен в формате OWL 2 посредством синтаксиса RDF/XML, описанного в рекомендации W3C [2].
<rdf:RDF xmlns=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1» xml:base=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1» xmlns:owl=«http://www.w3.org/2002/07/owl#» xmlns:rdf=«http://www.w3.org/1999/02/22-rdf-syntax-ns#» xmlns:xml=«http://www.w3.org/XML/1998/namespace» xmlns:xsd=«http://www.w3.org/2001/XMLSchema#» xmlns:rdfs=«http://www.w3.org/2000/01/rdf-schema#» xmlns:osawl=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1» xmlns:dcterms=«http://purl.org/dc/terms/»> <owl:Ontology rdf:about=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1»> <owl:versionIRI rdf:resource=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1»/> dcterms:creatorИванов Иван Иванович</dcterms:creator> dcterms:descriptionн/д</dcterms:description> <dcterms:issued rdf:datatype=«http://www.w3.org/2001/XMLSchema#date»>2023-05-30</dcterms:issued> dcterms:titleПространственный охват</dcterms:title> owl:versionInfov 1.0 2023-05-30.</owl:versionInfo>
</owl:Ontology>
<owl:AnnotationProperty rdf:about=«http://purl.org/dc/terms/creator»/>
<owl:AnnotationProperty rdf:about=«http://purl.org/dc/terms/description»/>
<owl:AnnotationProperty rdf:about=«http://purl.org/dc/terms/issued»/>
<owl:AnnotationProperty rdf:about=«http://purl.org/dc/terms/title»/>
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-07088557-fe0f-4d03-8204-
056ac79cbe92 -->
<owl:ObjectProperty rdf:about="https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-
07088557-fe0f-4d03-8204-056ac79cbe92«> <rdf:type rdf:resource=»http://www.w3.org/2002/07/owl#FunctionalProperty«/> <rdfs:domain rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-6e5b97a3- b085-4ff2-a883-47324b2d1c45«/> <rdfs:range rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-8d76ddaf- d69c-4bb9-b7dc-0c0dd156eceb«/> rdfs:labelимеет пространственный обхват</rdfs:label> </owl:ObjectProperty>»
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-2223cf88-8786-4e76-961f-
ed9e79a64cd6 -->
<owl:ObjectProperty rdf:about="https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-
2223cf88-8786-4e76-961f-ed9e79a64cd6«> <rdf:type rdf:resource=»http://www.w3.org/2002/07/owl#FunctionalProperty«/> <rdfs:domain rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-331a36d5- c9d5-427d-a9f2-bc94cd2a1b27«/> <rdfs:range rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-392ddb18- e57d-4943-8bab-c2d5d8896985«/> rdfs:labelимеет первым</rdfs:label> </owl:ObjectProperty>»
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-2ef0da03-c0b2-4022-8cbd-
0332d2d505c0 -->
<owl:ObjectProperty rdf:about="https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-
2ef0da03-c0b2-4022-8cbd-0332d2d505c0«> <rdf:type rdf:resource=»http://www.w3.org/2002/07/owl#FunctionalProperty«/> <rdfs:domain rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-331a36d5- c9d5-427d-a9f2-bc94cd2a1b27«/> <rdfs:range rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-392ddb18- e57d-4943-8bab-c2d5d8896985«/> rdfs:labelимеет последним</rdfs:label> </owl:ObjectProperty>»
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-830795f6-5e91-4812-82ca-
52c7b82e1200 -->
<owl:ObjectProperty rdf:about="https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-
830795f6-5e91-4812-82ca-52c7b82e1200«> <rdf:type rdf:resource=»http://www.w3.org/2002/07/owl#FunctionalProperty«/> <rdfs:domain rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-ff1308c5- ca29-41b7-9999-19bd6306d648«/> <rdfs:range rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-331a36d5- c9d5-427d-a9f2-bc94cd2a1b27«/> rdfs:labelопределяется посредством</rdfs:label> </owl:ObjectProperty>»
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-9233d8e7-daa4-48cc-9261-
47f965f55ec6 -->
<owl:ObjectProperty rdf:about="https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-
9233d8e7-daa4-48cc-9261-47f965f55ec6«> <rdf:type rdf:resource=»http://www.w3.org/2002/07/owl#FunctionalProperty«/> <rdfs:domain rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-8d76ddaf- d69c-4bb9-b7dc-0c0dd156eceb«/> <rdfs:range rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-ff1308c5- ca29-41b7-9999-19bd6306d648«/> <rdfs: label>содержит</rdfs:label> </owl:ObjectProperty>»
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-c80a3dc1-dd2e-4641-a85a-
7d46f3e04f4f -->
<owl:ObjectProperty rdf:about="https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-
c80a3dc1-dd2e-4641-a85a-7d46f3e04f4f«> <rdf:type rdf:resource=»http://www.w3.org/2002/07/owl#FunctionalProperty«/> <rdfs:domain rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-63ccff84- 1047-4317-80fc-41d0d245ca6a«/> <rdfs:range rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-09940ec0- d83b-4084-aeec-00695059f53d«/> rdfs:labelимеет систему координат</rdfs:label> </owl:ObjectProperty>»
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-d3275bb1-de63-459c-b85b-
0e5c6d978647 -->
<owl:ObjectProperty rdf:about="https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-
d3275bb1-de63-459c-b85b-0e5c6d978647«> <rdf:type rdf:resource=»http://www.w3.org/2002/07/owl#FunctionalProperty«/> <rdfs:domain rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-392ddb18- e57d-4943-8bab-c2d5d8896985«/> <rdfs:range rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-392ddb18- e57d-4943-8bab-c2d5d8896985«/> rdfs:labelимеет следующим</rdfs:label> </owl:ObjectProperty>»
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-edcc39a2-8f66-46ef-b5a2-
c77728ef23a9 -->
<owl:ObjectProperty rdf:about="https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-
edcc39a2-8f66-46ef-b5a2-c77728ef23a9«> <rdf:type rdf:resource=»http://www.w3.org/2002/07/owl#FunctionalProperty«/> <rdfs:domain rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-392ddb18- e57d-4943-8bab-c2d5d8896985«/> <rdfs:range rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-63ccff84- 1047-4317-80fc-41d0d245ca6a«/> rdfs:labelхарактеризуется посредством</rdfs:label> </owl:ObjectProperty>»
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-d23db662-04c5-41b3-a750-
375decaf0b84 -->
<owl:DatatypeProperty rdf:about="https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-
d23db662-04c5-41b3-a750-375decaf0b84«> <rdfs:domain rdf:resource=»https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-63ccff84- 1047-4317-80fc-41d0d245ca6a«/> <rdfs:range rdf:resource=»http://www.w3.org/2001/XMLSchema#float«/> rdfs:labelимеет значение координаты</rdfs:label> </owl:DatatypeProperty>»
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-09940ec0-d83b-4084-aeec-
00695059f53d -->
<owl:Class rdf:about=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-09940ec0-d83b- 4084-aeec-00695059f53d»> rdfs:labelСистема координат</rdfs:label> </owl:Class>
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-331a36d5-c9d5-427d-a9f2-
bc94cd2a1b27 -->
<owl:Class rdf:about=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-331a36d5-c9d5- 427d-a9f2-bc94cd2a1b27»> rdfs:subClassOf owl:Restriction <owl:onProperty rdf:resource=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id- 2223cf88-8786-4e76-961f-ed9e79a64cd6»/> <owl:minCardinality rdf:datatype=«http://www.w3.org/2001/XMLSchema#nonNegativeInteger»>1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> rdfs:subClassOf owl:Restriction <owl:onProperty rdf:resource=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id- 2ef0da03-c0b2-4022-8cbd-0332d2d505c0»/> <owl:minCardinality rdf:datatype=«http://www.w3.org/2001/XMLSchema#nonNegativeInteger»>1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> rdfs:labelПоследовательность пространственных объектов</rdfs:label> </owl:Class>
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-392ddb18-e57d-4943-8bab-
c2d5d8896985 -->
<owl:Class rdf:about=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-392ddb18-e57d- 4943-8bab-c2d5d8896985»> rdfs:subClassOf owl:Restriction <owl:onProperty rdf:resource=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id- edcc39a2-8f66-46ef-b5a2-c77728ef23a9»/> <owl:minCardinality rdf:datatype=«http://www.w3.org/2001/XMLSchema#nonNegativeInteger»>1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> rdfs:labelЭлемент последовательности пространственных объектов</rdfs:label> </owl:Class>
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-63ccff84-1047-4317-80fc-
41d0d245ca6a -->
<owl:Class rdf:about=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-63ccff84-1047- 4317-80fc-41d0d245ca6a»> rdfs:subClassOf owl:Restriction <owl:onProperty rdf:resource=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id- c80a3dc1-dd2e-4641-a85a-7d46f3e04f4f»/> <owl:minCardinality rdf:datatype=«http://www.w3.org/2001/XMLSchema#nonNegativeInteger»1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> rdfs:subClassOf owl:Restriction <owl:onProperty rdf:resource=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id- d23db662-04c5-41b3-a750-375decaf0b84»/> <owl:minCardinality rdf:datatype=«http://www.w3.org/2001/XMLSchema#nonNegativeInteger>1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> rdfs:labelТочка пространства</rdfs:label> </owl:Class>»
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-6e5b97a3-b085-4ff2-a883-
47324b2d1c45 -->
<owl:Class rdf:about=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-6e5b97a3-b085- 4ff2-a883-47324b2d1c45»> rdfs:subClassOf owl:Restriction <owl:onProperty rdf:resource=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id- 07088557-fe0f-4d03-8204-056ac79cbe92»/> <owl:minCardinality rdf:datatype=«http://www.w3.org/2001/XMLSchema#nonNegativeInteger»>1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> rdfs:labelПространственный объект</rdfs:label> </owl:Class>
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-8d76ddaf-d69c-4bb9-b7dc-
0c0dd156eceb -->
<owl:Classrdf:about=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-8d76ddaf-d69c- 4bb9-b7dc-0c0dd156eceb»> rdfs:subClassOf owl:Restriction <owl:onProperty rdf:resource=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id- 9233d8e7-daa4-48cc-9261-47f965f55ec6»/> <owl:minCardinality rdf:datatype=«http://www.w3.org/2001/XMLSchema#nonNegativeInteger»1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> rdfs:labelПространственный охват</rdfs:label> </owl:Class>
<!-- https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-ff1308c5-ca29-41b7-9999-
19bd6306d648 -->
<owl:Class rdf:about=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id-ff1308c5-ca29- 41b7-9999-19bd6306d648»> rdfs:subClassOf owl:Restriction <owl:onProperty rdf:resource=«https://example.com/workspace/b4b59744-6059-4286-86ae-7d07d4a4f8b1#id- 830795f6-5e91-4812-82ca-52c7b82e1200»/> <owl:minCardinality rdf:datatype=«http://www.w3.org/2001/XMLSchema#nonNegativeInteger»>1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> rdfs:labelВнутренняя часть</rdfs:label> </owl:Class> </rdf:RDF>
Б.1 При оценке качества пользовательских историй применяют критерии качества, объединенные в три группы (см. таблицу Б.1):
- синтаксические критерии качества, характеризующие только структуру текстов пользовательских историй без учета их значений;
- семантические критерии качества, оценивающие значения текстов пользовательских историй или отдельных их частей;
- прагматические критерии качества, учитывающие субъективную интерпретацию текстов пользовательских историй аудиторией.
Критерии качества пользовательских историй
| Критерий | Обозначение | Описание | Объект оценки |
| Критерий синтаксический: | |||
| хорошей сформированности | СИ1 | Пользовательская история включает как минимум выражения персоны и средства | Пользовательская история |
| атомарности | СИ2 | Пользовательская история выражает требование к одной особенности системы, для которой создается онтология | Пользовательская история о функциональном требовании |
| минимальности | СИ3 | Пользовательская история не содержит ничего, кроме выражений персоны, средства и целей | Пользовательская история о функциональном требовании |
| Критерий семантический: | |||
| концептуальной обоснованности | СЕ1 | Средства выражают особенность системы, для которой создается онтология, а цели выражают обоснование | Пользовательская история о функциональном требовании |
| проблемной ориентированности | СЕ2 | Пользовательская история указывает только на проблему, а не на ее решение | Пользовательская история |
| однозначности | СЕ3 | В пользовательской истории отсутствуют термины или абстракции, которые могут интерпретироваться неоднозначно | Пользовательская история |
| бесконфликтности | СЕ4 | Пользовательская история не должна противоречить любой другой пользовательской истории | Множество пользовательских историй |
| Критерий прагматический: | |||
| полного предложения | П1 | Пользовательская история — это правильно построенное полное предложение | Пользовательская история |
| оцениваемости | П2 | Пользовательская история должна быть сформулирована таким образом, чтобы ее оценка и планирование с уверенностью были возможными | Пользовательская история |
| уникальности | П3 | Каждая пользовательская история уникальна, дубликаты исключены | Множество пользовательских историй |
| унификации | П4 | Все пользовательские истории должны использовать один и тот же шаблон | Множество пользовательских историй о функциональных требованиях |
| независимости | П5 | Каждая пользовательская история является автономной и не имеет неотъемлемых зависимостей от других пользовательских историй <*> | Множество пользовательских историй |
| полноты | П6 | Множество пользовательских историй позволяет создать полнофункциональное приложение, функционирующее в рамках НСПД (не пропущен ни один шаг) | Множество пользовательских историй о функциональных требованиях |
| <*> Под отсутствием неотъемлемой зависимости понимается ситуация, при которой каждая пользовательская история может быть смоделирована независимо от других пользовательских историй. При этом результаты данного моделирования могут быть использованы при моделировании других пользовательских историй, что рассматривается как допустимая зависимость между пользовательскими историями. | |||
Допускается вводить дополнительные критерии качества в каждую группу.
Б.2 Оценка качества СПИ состоит из трех операций:
Б.3 Оценка качества каждой пользовательской истории представляет собой совокупность операций, включающих:
- определение значений критериев качества по логической шкале: если пользовательская история удовлетворяет критерию, ей присваивается значение один, в противном случае — ноль;
Б.4 Оценка качества множеств пользовательских историй представляет собой последовательность операций:
-
определение значений критериев качества по логической шкале: если множество пользовательских историй удовлетворяет критерию, ему присваивается значение один, в противном случае — ноль;
-
сравнение полученной суммы с количеством применимых для множества пользовательских историй данного типа критериев качества (N): если сумма значений всех применимых критериев качества равна N, множество пользовательских историй оценивается как высокого качества, в противном случае — как низкого качества.
Б.5 Итоговая оценка качества пользовательских историй состоит в присваивании всему набору пользовательских историй значения высокого качества, если каждая пользовательская история и набор пользовательских историй были оценены как высокого качества, и низкого качества в противном случае.
БИБЛИОГРАФИЯ
| УДК 528.852.1:004.658.4:006.354 | ОКС 35.240.70 |
| Ключевые слова: онтология, шаблон проектирования онтологий, компонент онтологии, тип онтологии, источник знаний для разработки онтологий | |