ГОСТ Р 70317-2022 Пространственные данные. Метаданные. Часть 3. Реализация XML-схемы для основных понятий

ГОСТ Р 70317-2022

(ISO/TS 19115-3:2016)

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Пространственные данные

МЕТАДАННЫЕ

Часть 3

Реализация XML-схемы для основных понятий

Spatial data. Metadata. Part 3. XML schema implementation for fundamental concepts

ОКС 35.240.70

Дата введения 2023-06-01

Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным бюджетным учреждением "Российский институт стандартизации" (ФГБУ "РСТ") и Федеральным государственным бюджетным учреждением "Федеральный научно-технический центр геодезии, картографии и инфраструктуры пространственных данных" (ФГБУ "Центр геодезии, картографии и ИПД") на основе официального перевода на русский язык англоязычной версии указанного в пункте 4 стандарта, который выполнен Федеральным государственным бюджетным учреждением "Российский институт стандартизации"

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

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

4 Настоящий стандарт является модифицированным по отношению к международному документу ISO/TS 19115-3:2016* "Географическая информация. Метаданные. Часть 3. Реализация XML-схемы для основных понятий" (ISO/TS 19115-3:2016 "Geographic information - Metadata - Part 3: XML schema implementation for fundamental concepts", MOD) путем включения дополнительных фраз, слов, ссылок и внесения изменений по отношению к тексту применяемого международного стандарта, которые выделены курсивом**. Объяснение причин внесения этих технических отклонений приведено во введении.

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте, приведены в приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации"***. Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

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

В ГОСТ Р 57668 объяснена значимость метаданных, представлена модель для описания географических информационных ресурсов путем определения сущностей метаданных, элементов и терминологии и установления процедуры расширения для дополнительного содержимого метаданных, а также включены элементы метаданных, описывающие веб-сервисы (см. [1] и [2]). Более подробно метаданные для конкретных типов пространственных данных и качества данных рассмотрены в других стандартах, например в ГОСТ Р 57773. При необходимости интерпретации других стандартов ИСО по географической информации включены в настоящий стандарт.

В ГОСТ Р 57656 в отличие от ГОСТ Р 57668 добавлены модели информации о сборе данных и расширены модели метаданных (MD_Metadata), пространственного представления (MD_SpatialRepresentation) и информации о содержимом (MD_Contentlnformation).

В ГОСТ Р 57668 и ГОСТ Р 57656 представлены концептуальные модели для содержимого метаданных, которые не зависят от конкретной схемы кодирования [схемы расширяемого языка разметки (XML) для кодирования этого содержимого см. в [3] и [4]]. Настоящий стандарт определяет XML-кодирование для содержимого метаданных, соответствующих метаданным, приведенным в ГОСТ Р 57668 и ГОСТ Р 57656. Такая объединенная схема позволяет использовать понятия, применяемые в ГОСТ Р 57668 и ГОСТ Р 57656, одновременно в экземплярах документов метаданных, эффективно заменяя понятия с учетом [3] и [4], и дает возможность автоматизировать проверки и обмен содержимого метаданных, соответствующих ГОСТ Р 57668 и ГОСТ Р 57656, посредством стандартных программных средств.

Объединенная схема получена на основе концептуальных моделей ГОСТ Р 57668 и ГОСТ Р 57656 с использованием правил, определенных в [5] (приложение А), [3], примененных к принятой готовой к реализации UML-версии концептуальных моделей, как описано в разделе 8. Подход к реализации обеспечивает модульность и облегчает многократное использование элементов концептуальных моделей. Абстрактные классы добавлены к согласованной модели ИСО по географической информации без изменения семантики для создания модели реализации, которая использовалась для XML-схемы (подробности см. в разделе 8).

Основным вариантом использования, предусмотренным в реализации XML-схемы, является обмен географическими метаданными в среде клиент-сервер, например Всемирная паутина (World Wide Web), в которой внутреннее управление и структура содержимого метаданных не зависят от кодировки, используемой для обмена информацией метаданных. Принятие XML-схемы географических метаданных в рамках сообщества обмена информацией позволит получить преимущества стандартизации для обнаружения, доступа, использования и понимания пространственных данных.

Настоящий стандарт разработан с целью пояснения отдельных положений и приведения в соответствие с действующими национальными стандартами, такими как ГОСТ Р 57668 и ГОСТ Р 57656.

1 Область применения

Настоящий стандарт определяет объединенную XML-реализацию по ГОСТ Р 57668, ГОСТ Р 57656 и понятий (см. [3]) посредством следующих артефактов:

a) набор XML-схем, необходимых для проверки экземпляров документов метаданных, соответствующих элементам концептуальной модели, определенным в ГОСТ Р 57668, ГОСТ Р 57656 и [3];

b) набор правил (см. [6]), реализующих ограничения проверки в моделях UML по ГОСТ Р 57668 и ГОСТ Р 57656, которые не проверяются XML-схемой;

c) преобразование расширяемого языка стилей (XSLT) для преобразования метаданных по ГОСТ Р 57668, закодированных с помощью XML-схемы в соответствии с [3], и метаданных по ГОСТ Р 57656, закодированных с помощью XML-схемы (см. [4]), в эквивалентный документ, действительный в отношении XML-схемы, определенной в настоящем стандарте.

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

Эта модель реализации не изменяет семантику целевой концептуальной модели, но добавляет абстрактные классы, которые удаляют зависимости между пакетами моделей, теговыми значениями и стереотипами, необходимые для программного обеспечения преобразования UML в XML, и рефакторирует упаковку некоторых элементов в пространства имен XML. XML-схема сгенерирована из модели UML для ее реализации в соответствии с определенными правилами (см. [3] или [5]).

2 Соответствие

2.1 Общие положения

Для того чтобы претендовать на соответствие классу соответствия, определенному в настоящем стандарте, экземпляр XML-схемы должен пройти проверку на соответствие процедурам тестирования, указанным в приложении А. Эти тесты включают проверку с использованием определенного документа XML-схемы, а также документов правил Schematron, которые проверяют соответствие ограничениям, заданным базовой концептуальной моделью, которые не проверяются XML-схемой. Каждый модуль пространства имен и схема документа обмена, определенные реализацией, несут с собой неявный класс соответствия для экземпляров документов XML. Этот класс соответствия проверяет требование, чтобы экземпляры элементов XML и атрибутов из пространства имен были правильно сформированы и действительны. Тест представляет собой проверку с помощью определенной XML-схемы и, если это необходимо, набора правил Schematron. Структура, концепции и методология тестирования, а также критерии, которые должны быть достигнуты для утверждения соответствия, указаны в ГОСТ Р ИСО 19105.

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

2.2 Классы соответствия для модулей метаданных

В настоящем стандарте определен набор классов соответствия для различных модулей содержимого, приведенных в ГОСТ Р 57668 и ГОСТ Р 57656, чтобы разрешить их использование в качестве компонентов в других реализациях документов обмена. Каждый модуль упакован в отдельное пространство имен XML. В таблице 1 перечислены модули, представленные в настоящем стандарте.

Таблица 1 - Классы соответствия, определенные для модулей метаданных

_______________

2.3 Классы соответствия для документов обмена метаданными

В настоящем стандарте определен набор XML-схем, которые импортируют различные модульные компоненты пространства имен для определения полезных документов обмена метаданными. Каждая из этих схем документов имеет связанные требования и класс соответствия, а также URI пространства имен для идентификации типа документа. В таблице 2 перечислены эти схемы документов обмена.

Таблица 2 - Классы соответствия для обмена метаданными

3 Нормативные ссылки

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

ГОСТ 7.67 (ИСО 3166-1:1997) Система стандартов по информации, библиотечному и издательскому делу. Коды названий стран

ГОСТ 7.75 Система стандартов по информации, библиотечному и издательскому делу. Коды наименований языков

ГОСТ Р 57656-2017 (ИСО 19115-2:2009) Пространственные данные. Метаданные. Часть 2. Расширения для изображений и матричных данных

ГОСТ Р 57668-2017 (ИСО 19115-1:2014) Пространственные данные. Метаданные. Часть 1. Основные положения

ГОСТ Р 57773 (ИСО 19157:2013) Пространственные данные. Качество данных

ГОСТ Р ИСО 19105 Географическая информация. Соответствие и тестирование

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

4 Термины и определения

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

4.1 пространственные объекты (spatial objects): Природные объекты, искусственные и иные объекты (в том числе здания, сооружения), местоположение которых может быть определено, а также естественные небесные тела.

Примечание - См. [7] (статья 3).

4.2 пространственные данные (spatial data): Данные о пространственных объектах, включающие сведения об их форме, местоположении и свойствах, в том числе представленные с использованием координат.

Примечание - См. [7] (статья 3).

4.3 сведения о пространственных данных (пространственные метаданные) (spatial metadata): Данные, которые позволяют описывать содержание и другие характеристики пространственных данных, необходимые для их идентификации и поиска.

Примечание - См. [7] (статья 3).

4.4 пространство имен (namespace): Совокупность имен XML, определяемых по ссылке URI, которые используются в XML-документах в качестве имен элементов и имен атрибутов.

Примечание - Комбинация URI пространства имен и имени элемента или имени атрибута должна быть глобально уникальным идентификатором для этого элемента модели.

4.5 пакет в UML: Механизм общего назначения для организации элементов в группы.

Пример - Идентификационная информация, информация о наборе сущностей метаданных, информация об ограничениях.

Примечания

1 Пакеты могут быть вложены в другие пакеты. В пакете могут быть отображены как элементы модели, так и диаграммы.

2 Пакет предоставляет пространство имен для сгруппированных элементов.

4.6 реализация (realization): Семантическая связь между классификаторами, при осуществлении которой один классификатор задает условия, а другой классификатор гарантирует их исполнение.

Примечание - Реализация означает наследование поведения без наследования структуры.

4.7 полиморфизм (polymorphism): Характеристика возможности задавать различное толкование или использование чего-либо в разных контекстах, в частности: чтобы сущность, такая как переменная, функция или объект, могла иметь более одной формы.

5 Сокращения

5.1 Список сокращений

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

5.2 Пространства имен

Пространства имен XML, определенные в настоящем стандарте, идентифицируются URI, которые соответствуют шаблону //standards.iso.org/iso/19115/-3/xxx/N.M, где xxx - аббревиатура пространства имен из трех буквенно-цифровых символов, N - номер основной версии, а M - номер дополнительной версии. При разыменовании URI пространства имен в качестве указателя ресурса будут получены: описание пространства имен, ссылки на описание содержимого пространства имен и ссылки на базовую спецификацию, реализуемую пространством имен, и на расположение нормативной XML-схемы.

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

Таблица 3 - URI внешних пространств имен и соглашения об аббревиатурах пространств имен, используемые в настоящем стандарте

_______________

В таблицах 4 и 5 перечислены аббревиатуры и приведена другая информация для пространств имен, используемых для пакетов UML, определенных в ГОСТ Р 57668, и для пространств имен, определенных в настоящем стандарте, которые импортируют несколько пространств имен XML для указания типов документов обмена.

Таблица 4 - URI пространства имен и соглашения об аббревиатурах пространства имен, определенные и используемые в настоящем стандарте для пакетов, определенных в ГОСТ Р 57668

Таблица 5 - URI пространств имен и соглашения об аббревиатурах пространств имен для идентификации типов документов обмена метаданными, объединяющих несколько пространств имен

6 Требования

6.1 Автоматическая генерация XML-схемы

Первая задача разработки информационных моделей стандартов ИСО по географической информации состоит в том, чтобы обеспечить создание XML-схемы в соответствии со стандартными правилами и шаблонами реализации таким образом, чтобы машинная обработка моделей UML могла генерировать XML-схему. Цель заключается в том, чтобы способствовать предсказуемости, расширяемости, повторному использованию схемы и совместимости с другими реализациями стандартов ИСО по географической информации. Полученные XML-схемы алгоритмически выводятся из нормативных моделей UML для стандартов ИСО по географической информации, что способствует согласованности в полученной схеме. Данные схемы предсказуемы, так как классы UML, атрибуты, ассоциации и т.д. кодируются в соответствии с последовательными правилами и шаблонами.

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

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

6.2 Многоязычная адаптивность и полиморфизм

Культурная и лингвистическая адаптивность является требованием к элементам метаданных с текстовым содержимым. В ГОСТ Р 57668-2017 (приложение F) рассмотрены элементы многоязычных текстовых метаданных. Для обеспечения совместимости многоязычных экземпляров документов XML-реализация следует реализации, определенной в [3]. Кодировки типов свойств, описанные в [3], включают расширения XML-схемы, реализующие значения свойств с использованием типов элементов, не включенных в базовую XML-схему. Такой полиморфизм позволяет сообществам пользователей изменять географические метаданные для удовлетворения своих организационных потребностей. Этот шаблон используется для обеспечения поддержки культурной и лингвистической адаптивности посредством экземпляров документов метаданных, содержащих наполнение на одном или нескольких языках, которые не нарушают правила кардинальности, определенные в ГОСТ Р 57668. Пространство имен Ian определяет тип свойства CharacterString, который включает значение CharacterString и от нуля до многих элементов PT_FreeText, каждый из которых является языково-локализованной символьной строкой, которая может быть включена подстановкой или по ссылке. Используя это расширение, один документ метаданных может включать строки содержимого на различных языках, но пользовательские программы, которые не запрограммированы для многоязычного содержимого, тем не менее будут работать, так как присутствует стандартный элемент CharacterString.

Другим примером полиморфизма является атрибут name типа CharacterString в классе CI_Individual по ГОСТ Р 57668. Если требуется более структурированное представление (например, элементы имени, отчества и фамилии), полиморфизм позволяет расширить реализацию элемента name в определяемом пользователем пространстве имен, которое может быть заменено на CharacterString в экземпляре метаданных. Эти расширения будут понятны пользователям, которые распознают пространство имен расширений, но в целом такие расширения не будут взаимодействовать с клиентским программным обеспечением, не предназначенным для работы с ними.

6.3 Введение в классы требований

Требования к созданию действительных экземпляров метаданных XML для концептуальной модели, представленной в ГОСТ Р 57668, определены в 6.4-6.7. В таблицах 6-10 адреса HTTP URI использованы для идентификации подразделов в соответствующих стандартах ИСО, которые не определяют и не назначают идентификаторы классам требований и классам соответствия, на которые можно ссылаться в настоящем стандарте. Эти адреса построены с использованием //standards.iso.org/iso в качестве основы совместно с идентификатором исходного проекта, номером издания и "spec#N.N.N" в качестве окончательного токена, где часть "N.N.N" идентифицирует раздел источника в стандартах. Каждый реализованный пакет устанавливает требования для проверки экземпляров XML, использующих элементы из пакета. Требования сгруппированы в основные требования, которые применяют при проверке всех экземпляров, в требования к модулям метаданных, которые определяют различные компоненты содержимого метаданных, и в требования к фактическим документам обмена метаданными, сбор которых осуществлен путем импорта коллекций модулей. Модули метаданных предназначены для минимизации зависимостей между модулями для того, чтобы упростить их повторное использование в другой прикладной схеме.

6.4 Основные требования

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

Таблица 6 - Требования к ядру метаданных

_______________

6.5 Требования к модулям метаданных

Коллекцию модульных пространств имен XML используют для реализации пакетов разного содержания, определенных в ГОСТ Р 57668 и ГОСТ Р 57656. Модули сведены в таблицу 7, а в таблице 8 для каждого модуля определены требования к экземплярам XML и присвоены идентификаторы. Эти идентификаторы упоминаются в определении классов соответствия и тестах в приложении А.

Таблица 7 - Сводка модулей метаданных, определенных в настоящем стандарте

Таблица 8 - Классы требований для экземпляров документов XML для каждого модуля пространства имен

6.6 Требования к документам для обмена метаданными

Для повышения совместимости метаданных настоящий стандарт определяет классы соответствия для шести типов экземпляров документов метаданных, которые постепенно реализуют больше возможностей для описания ресурсов и их взаимосвязей (см. таблицу 9). Наиболее простым является класс требований Minimal-Metadata-lnstance (экземпляр минимальных метаданных), который определяет документ метаданных, использующий элементы в пространствах имен в соответствии с настоящим стандартом, необходимые для соблюдения минимальных обязательных требований к содержимому согласно модели ГОСТ Р 57668 для метаданных набора данных.

Класс требований к метаданным для данных или сервисов определяет тип документа, который использует модули пространства имен в соответствии с настоящим стандартом, для реализации всех свойств, указанных для записи метаданных, заданной в моделях ГОСТ Р 57668 и ГОСТ Р 57656, за исключением расширений типов (gcx) и расширений метаданных (mex). Такой тип документа обеспечивает полную запись метаданных, описывающую любой тип геопространственного ресурса или сервиса, включая информацию о сборе данных, определенную в ГОСТ Р 57656.

Класс требований к метаданным с расширенными типами задает тип документа, который расширяет требования к метаданным для данных или сервисов, позволяя заменять строки символов из пространства имен геопространственных общих расширений (gcx) (первоначально определенного в [3]).

Класс требований к метаданным с расширенным содержимым задает тип документа, который расширяет требования к метаданным для данных или сервисов, предоставляя как замену символьных строк из пространства имен геопространственных общих расширений (gcx), так и замену расширений схемы метаданных, определенной ГОСТ Р 57668 и ГОСТ Р 57656 с использованием пространства имен расширений метаданных и процедуры согласно ГОСТ Р 57668-2017 (6.5.12). Профили пользователей и расширения для метаданных рассмотрены в ГОСТ Р 57668-2017 (приложение С) с правилами, связанными с надлежащим анализом требования к расширению, и с полученной документацией для описания расширения. Правила, задающие требования для реализации различных типов расширения в соответствии с ГОСТ Р 57668-2017 (С.2 приложения С), перечислены в [3]. Эти правила были использованы для определения требований, перечисленных в таблице 9.

Класс требований к экземпляру приложения метаданных задает тип документа, который реализует модель приложения метаданных, определенную в ГОСТ Р 57668-2017 (6.2). Эта модель предназначена для поддержки метаданных, описывающих иерархические агрегаты данных или коллекции, путем определения нескольких классов для представления различных типов агрегатов, являющихся подтипами абстрактного класса DS_Resource. Концептуальная модель определяет двунаправленную ассоциацию между DS_Resource и элементом Metadata lnformation::MD_Metadata. Реализация двунаправленной ассоциации делает невозможной модуляризацию модели метаданных из-за циклических зависимостей, которые она вводит. Таким образом, в настоящем стандарте реализована только ассоциация от DS_Resource к MD_Metadata, но не обратная ассоциация от MD_Metadata к DS_Resource. Это основано на анализе того, что в реальных приложениях предпочтительный сценарий состоит в том, чтобы связать ресурс с метаданными, описывающими ресурс, и что свойство associatedResource в MD_Identification может быть использовано для реализации взаимосвязи записи метаданных с описанными экземплярами ресурса, при необходимости.

Класс требований к экземпляру метаданных для передачи данных задает тот тип документа, который реализует модель метаданных для передачи данных (см. [3]). Эта модель реализована в настоящем стандарте для совместимости с ГОСТ Р 57668 и предоставляет тот каталог (определенный в пространстве имен cat), который перечисляет содержимое агрегации набора данных, описанной записью метаданных, и позволяет вспомогательным файлам связываться с агрегатом или с компонентами наборов данных.

Таблица 9 - Классы требований для типов документов, используемых для обмена метаданными и связанной информацией

В таблице 10 приведены элементы, определенные в ГОСТ Р 57668 как обязательные в каждом экземпляре документа метаданных, который не описывает сервис.

Таблица 10 - Сводка обязательных элементов для класса соответствия минимального экземпляра документа в соответствии с ГОСТ Р 57668

6.7 Диаграммы зависимостей требований

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

Каждый из этих классов требований связан с тем классом соответствия, который устанавливает тесты для определения соответствия экземпляров документов указанным требованиям. Необходимо обратить внимание на добавление классов требований, которые определяют записи метаданных, включающие все необязательные модули содержимого метаданных (экземпляр полной записи метаданных), геопространственные общие расширенные типы (см. [3]) (метаданные с геопространственными общими расширенными типами), а также расширения модели содержимого метаданных в соответствии с положениями ГОСТ Р 57668 (см. также [3]) (экземпляр метаданных с расширенным содержимым). Эти классы требований не требуют реализации новых элементов метаданных. Классы соответствия для данных классов требований реализованы через XML-схемы, которые имеют один и тот же корневой элемент MD_Metadata и импортируют необходимую XML-схему, определенную в классах соответствия модуля метаданных (и во внешней схеме в некоторых случаях). URI пространств имен, связанных с этими классами требований, использованы в качестве значений атрибутов целевого пространства имен в документах схем и экземплярах документов для указания соответствия такому классу требований. URI расположений схем указывают на XML-схему, используемую для проверки соответствия определенному классу соответствия.

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

Рисунок 1 - Зависимости между классами требований к кодированию

7 Расширения к моделям UML в серии международных стандартов ИСО по географической информации для XML-схемы

Реализация XML-схемы включает в себя расширения модели, определенные в [3] для веб-среды (геопространственные общие расширенные типы), культурную и лингвистическую адаптивность и каталоги. Поскольку некоторые из расширений (см. [3]) импортируют элементы из пространства имен //www.isotc211.org/2005/gmd, новые реализации схемы XML этих расширений включены в настоящий стандарт для совместимости и связаны в пространствах имен языка (Ian), общего расширения метаданных (gcx) и каталога (cat). Модель реализации также включает в себя пакет абстрактных классов, используемых для реализации необязательных типов свойств классов (см. 8.2), и пакеты для агрегирующих пространств имен, перечисленных в A.2.3 приложения A.

8 Подход и правила кодирования

8.1 Пакеты UML и пространства имен XML

Процедура для кодирования понятий по ГОСТ Р 57668 в схему XML (см. [3]) объединила понятия из многих пакетов UML в одно пространство имен XML (gmd). Этот подход, с одной стороны, упростил полученные в результате экземпляры документов XML, но, с другой стороны, затруднил независимое повторное использование концепций конкретных пакетов UML. Целью настоящего стандарта является определение отношений между пакетами UML и пространствами имен XML таким образом, чтобы обеспечить их модульность и многократное применение. Правила, контролирующие отношения между пакетами и пространствами имен, используемыми в настоящем стандарте, следующие:

a) реализация XML-схемы будет включать как минимум одно пространство имен для каждого пакета UML в концептуальной модели, т.е. несколько пакетов UML не должны быть объединены в одно пространство имен;

b) пакеты UML могут быть разделены на несколько пространств имен, если это необходимо для упрощения реализации и управления жизненными циклами различных компонентов;

c) исключения из правила по перечислению a) могут потребоваться для минимизации зависимостей между пространствами имен и устранения циклических зависимостей.

8.2 Модель UML для реализации XML-схемы

В ГОСТ Р 57668 определены ряд пакетов UML и отношения между ними. Эти отношения приводят к зависимостям между теми пакетами, которые делают невозможным их повторное использование без включения всей модели. Для обеспечения модульности и автоматической генерации схемы в модель UML добавлен специфичный для XML-схемы уровень реализации, не влияющий на ее семантику. Этот уровень включает абстрактные классы, которые позволяют разделять пакеты моделей, добавлять теговые значения и стереотипы, необходимые для программного обеспечения преобразования UML в XML, и рефакторинг некоторых пакетов элементов модели, где это требуется для устранения циклических зависимостей между пространствами имен XML. Абстрактные классы также созданы для определения групп подстановок для тех классов, которые используются или могут использоваться реализациями XML-схем других моделей ИСО. Абстрактные классы для связи между пространствами имен упакованы в один пакет. Измененная модель UML называется моделью реализации, и XML-схема была автоматически сгенерирована из этой модели реализации в соответствии с определенными правилами (см. [5] и [3]).

8.3 Подход к реализации для разделения XML-пакетов

8.3.1 Общие положения

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

Ассоциации между классами UML могут быть смоделированы как значения атрибутов или концы ассоциаций. Подход реализации необходим в тех случаях, когда необязательный атрибут или ассоциация имеет тип свойства, который является классом из пакета, отличного от пакета, содержащего элемент. Экземпляры документов XML следует проверять с/без импорта пространства имен, которое реализует необязательный класс типа свойства. Это достигается путем использования абстрактного класса для типа значения свойства в схеме для родительского элемента (MD_Metadata на рисунке 2) и конкретной заменой этого абстрактного класса в схеме для элемента-потомка (LI_Lineage на рисунке 2), который обеспечивает фактическую реализацию класса значения свойства.

Шаблон более подробно показан на рисунке 3; реализация XML-схемы представлена в примерах 1-3. Класс MD_Metadata входит в пространство имен базы метаданных (mdb), которое импортирует абстрактный класс _Lineagelnformation из пространства имен общих классов метаданных (mcc). Пространство имен mcc включено во все классы соответствия. Конкретной реализацией класса _Lineagelnformation является класс LI_Lineage, определенный в пространстве имен метаданных о происхождении ресурса (mrl). Соответствующие экземпляры документов не должны импортировать пространство имен mrl, если они фактически не включают информацию о происхождении. Пространство имен метаданных о происхождении ресурса (mrl) не должно импортировать пространство имен базы метаданных (mdb) для проверки, что позволяет использовать его в качестве автономного модуля в другой прикладной схеме, которая может связать происхождение с каким-либо элементом модели.

Пример 1 - Ассоциация от базового класса метаданных к абстрактному типу свойства. В пространстве имен базового класса (mdb) определяется базовый элемент метаданных, который имеет необязательное свойство для различных классов деталей метаданных (см. рисунок 2). Базовый класс импортирует пространство имен, которое содержит определения совместно используемых абстрактных элементов.

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

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

<import namespace="//standards.iso.org/iso/19115/-3/mcc/1.0/"

=//standards.iso.org/iso/19115/-3/mcc/1.0/schemaLocation="../../mcc/1.0/mcc.xsd"/>

<!-- элементы схемы пропущены -->

<!-- корневая сущность, которая определяет метаданные о ресурсе или ресурсах -->

<element name="MD_Metadata" substitutionGroup="gco:AbstractObject"

type="mdb:MD_Metadata_Type"/>

<!-- определение типа для корневого элемента, сложное содержимое - это

последовательность свойств -->

<complexType name="MD_Metadata_Type">

<complexContent>

<extension base="gco:AbstractObject_Type">

<sequence>

<!-- элементы пропущены... -->

<element maxOccurs="unbounded" minOccurs="0" name="resourceLineage"

type="mcc: Abstract_LineageInformation_PropertyType"/ >

<!-- тип для resourceLineage - это абстрактный класс из mcc -->

<!-- элементы пропущены... -->

</sequence>

</extension>

</complexContent>

</complexType>

Пример 2 - Определение абстрактного элемента в пакете абстрактных классов (mcc); этот пакет является связующим звеном для использования модульных пакетов. Абстрактные элементы не имеют содержимого.

Глобальный элемент класса XML, соответствующий классу (LI_Lineage), который является типом свойства для необязательного атрибута (resourceLineage) в базовом классе (см. рисунок 3).

<element abstract="true" name="Abstract_LineageInformation"

substitutionGroup="gco:AbstractObject"type="mcc:Abstract_LineageInformation_Type"/>

Тип класса XML для абстрактного класса:

<complexType abstract="true" name="Abstract_LineageInformation_Type">

<complexContent>

<extension base="gco:AbstractObject_Type">

<sequence/> <!-- без содержимого -->

</extension>

</complexContent>

</complexType>

Примечание - Абстрактный класс реализован в пространстве имен общих классов метаданных и используется как цель необязательного свойства. Чтобы создать экземпляр свойства в экземпляре ХМL, необходимо импортировать пространство имен, которое содержит конкретный класс в группе подстановок для абстрактного класса (mrl.xsd на этой диаграмме).

Рисунок 3 - Шаблон реализации для необязательных свойств с классом типа данных в другом пакете

Стандартное кодирование типа свойства класса XML для абстрактного типа свойства класса:

<complexType name="Abstract_LineageInformation_PropertyType">

<sequence minOccurs="0">

<element ref="mcc:Abstract_LineageInformation"/>

</sequence>

<attributeGroup ref="gco:ObjectReference"/>

<attribute ref="gco:nilReason"/>

</complexType>

Пример 3 - Определение конкретного класса в группе подстановок для абстрактного класса, в отдельном пространстве имен (mrl).

<element name="LI_Lineage" substitutionGroup="mcc: Abstract_LineageInformation"

type="mrl:LI_Lineage_Type"/>

<!-- сложный тип расширяет тип абстрактного класса -->

<complexType name="LI_Lineage_Type">

<complexContent>

<extension base="mcc:Abstract_LineageInformation_Type">

<sequence>

<!-- определение элементов в конкретном экземпляре... -->

</sequence>

</extension>

</complexContent>

</complexType>

Реализация метаданных, которая будет использовать элемент Ll_Lineage, должна импортировать пространство имен mrl.

8.3.2 Подход к реализации для разделения необязательных классов

UML-модель для реализации XML-схемы использует следующий шаблон для классов, которые являются типом данных для значений свойств: если тип значения свойства - это класс, реализуемый в таком же пакете UML, как и владеющий класс, изменения отсутствуют. Если тип значения свойства является классом, который реализован в другом пакете UML, то в настоящем стандарте (абстрактный шаблон, показанный на рисунке 4) пространства имен разделяются путем введения абстрактного класса в пакет абстрактных классов в UML-модели реализации. Конкретный класс, реализующий абстрактный класс, определяется в пакете для пространства имен реализации как специализация абстрактного класса, создавая зависимость между пакетом реализации, содержащим класс, и пакетом абстрактных классов. Затем этот шаблон UML реализуется с использованием правил кодирования (см. [3]) для абстрактных классов. Введение абстрактного класса не изменяет семантику реализуемой модели, но позволяет определять новые версии конкретного реализующего класса без влияния на схему, использующую абстрактный класс. Таблица 6 представляет собой список классов по ГОСТ Р 57668 в UML для реализации XML настоящего стандарта, которые используют этот шаблон.

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

a) Абстрактный класс и тип свойства определены в пакете пространства имен XML абстрактных общих классов, который обозначен аббревиатурой пространства имен "acn". Это пространство имен определяет все абстрактные классы, которые используются для связывания модулей в автономном режиме. При этом пакет абстрактного класса представлен в UML-модели реализации и является исключительно артефактом реализации. Экземпляры документов XML не будут содержать элементы из этого пакета.

Пример 1 - Шаг a) определяет абстрактный класс (в данном примере с именем acn:AbstractClass2) (см. [3]).

<schema xmlns:acn=//standards.iso.org/iso/19115/-3/acn/1.0 ... />

<element abstract="true" name="AbstractClass2" substitutionGroup="gco:AbstractObject"

type="acn:AbstractClass2_Type"/>

<complexType abstract="true" name="AbstractClass2_Type">

<complexContent>

<extension base="gco:AbstractObject Type">

<sequence/> <!-- без содержимого -->

</extension>

</complexContent>

</complexType>

Примечание - Свойства внутри класса 2 не показаны.

Рисунок 4 - Пример необязательного свойства, имеющего тип свойства класса

Пример 2 - На шаге a) реализация типа свойства со значением, заданным абстрактным классом согласно примеру 1 (см. [3]).

<complexType name=" AbstractClass2_PropertyType">

<sequence minOccurs="0">

<element ref=" acn:AbstractClass2"/>

</sequence>

<attributeGroup ref="gco:ObjectReference"/>

<attribute ref="gco:nilReason"/>

</complexType>

b) Другое пространство имен (обозначенное аббревиатурой "ns1" в примере 3) содержит класс, который имеет необязательное свойство (кардинальность 0..1 или 0..*), которое задается абстрактным классом, определенным выше. Пространство имен XML, реализующее этот класс, должно импортировать пространство имен, содержащее определения совместно используемых абстрактных элементов [аббревиатура "can", приведенная в примерах 1 и 2 перечисления a)].

Пример 3 - На шаге b) реализация XML-схемы для пространства имен ("ns1"), которое определяет класс (Class1) со свойством, имеющим тип данных, указанный абстрактным классом, приведенным в примерах 1 и 2 перечисления а).

<schema xmlns:nsl=//standards.iso.org/iso/19115/-3/ns1/1.0 ... />

Импорт пространства имен xml абстрактных классов:

<import namespace="//standards.iso.org/iso/19115/-3/acn/1.0/"

schemaLocation="../../acn/1.0/acn.xsd"/>

<!-- корневая сущность -->

<element name="Class1" substitutionGroup="gco:AbstractObject" type="ns1:Class1_Type">

</element>

Определение типа класса для Class1 со свойством (названным "property"), значение которого определено типом свойства AbstractClass2:

<complexType name="Class1_Type">

<complexContent>

<extension base="gco:AbstractObject_Type">

<sequence>

(....)

<element maxOccurs="unbounded" minOccurs="0" name="property"

type="acn:AbstractClass2_PropertyType "/>

(....)

</sequence>

</extension>

</complexContent>

</complexType>

c) Третье пространство имен (обозначенное аббревиатурой "ns2") определяет конкретный XML-элемент (Class2, рисунок 4), который является членом группы подстановок для абстрактного класса (AbstractClass2). XML-экземпляры класса Class1 должны импортировать как пространство имен "acn", так и пространство имен, включающее конкретный класс, который заменяет AbstractClass2 [например, Class2 в примере 3 перечисления в)], чтобы предоставить экземпляры свойства "property" (см. рисунок 4).

Пример 4 - На шаге c) реализация XML-схемы для пространства имен ("ns2"), которая определяет конкретный класс (Class2) в группе подстановок для AbstractClass2.

<element name="Class2" substitutionGroup="acn:AbstractClass2" type="ns2:Class2_Type"/>

<!-- сложный тип расширяет тип для абстрактного класса -->

<complexType name="Class2_Type">

<complexContent>

<extension base="acn:AbstractClass2_Type">

<sequence>

<!-- определение элементов в конкретном экземпляре... -->

</sequence>

</extension>

</complexContent>

</complexType>

8.4 Правила кодирования XML

Пространство имен //standards.iso.org/iso/19115/-3/mcc/1.0 включает элементы, реализующие абстрактные классы, необходимые для кодирования типов необязательных свойств классов, определенных в ГОСТ Р 57668** в соответствии с правилом реализации в разделе 8. В таблице 11 приведены необходимые классы.

В разделах 7-9 [3] описаны детали кодирования концептуальной схемы UML в набор XML-схем. Реализация XML-схемы согласно настоящему стандарту следует правилам и шаблонам, описанным в этих разделах, применяя их к модели UML для реализации XML. Одно дополнительное правило потребовалось для поддержки модели реализации, описанной в 8.2, и для улучшения модульности реализации XML-схемы. В таблице 12 перечислены правила кодирования, используемые для каждого класса UML.

Таблица 11 - Сводка свойств, реализованных с абстрактным элементом в качестве типа данных

8.5 Значения по умолчанию

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

- defaultLocale language ="en" как для метаданных, так и для идентификации данных;

- defaultLocale character set code ="UTF-8" как для метаданных, так и для идентификации данных;

- MD_Metadata.metadataScope.MD_MetadataScope.resourceScope code ="dataset".

Таблица 12 - Правила кодирования, используемые для генерации XML-схемы для настоящего стандарта

Приложение A

(обязательное)

Комплект абстрактных тестов

A.1 Обзор

A.1.1 Инструменты тестирования соответствия

Различные тесты соответствия для настоящего стандарта требуют, чтобы экземпляры документов метаданных (XML) могли быть проверены на отсутствие ошибок в отношении XML-схем. Несмотря на то, что для проверки правильности экземпляров документов XML в соответствии с предоставленными XML-схемами доступно множество инструментов, следует учитывать, что не все средства проверки по XML-схеме реализуют рекомендацию W3C полностью и не все средства проверки по XML-схеме интерпретируют рекомендацию W3C одинаковым образом. При проверке экземпляров документов XML по тестам соответствия рекомендуется использовать средство, реализующее строгую интерпретацию и полную поддержку XML-схемы W3C.

Нормативная XML-схема и документы Schematron доступны в каталоге по адресу: //standards.iso.org/iso/19115/-3/, со структурой каталогов, описанной в приложении B. В приложении C приведены дополнительные сведения о схеме кодирования; в приложении D - два примера экземпляров документов, соответствующих схеме реализации.

A.1.2 Требования к соответствию. Ограничения проверки XML-схемы

Так как проверки XML-схемы недостаточно для проверки всех ограничений, приведенных в ГОСТ Р 57668, для некоторых тестов соответствия требуются другие процедуры проверки. Например, элемент свойства, следующий за шаблоном типа свойства класса XML (ХСРТ) по умолчанию (см. [3]), может иметь одно из следующего: встроенного содержимого (по значению), которое является XML-классом; атрибута xlink: href (по ссылочному значению) или атрибута gco:nilReason (nil-значение). Поскольку XML-схема не может ограничивать совместное вхождение содержимого или атрибутов, необходимо использовать некоторый механизм в дополнение к проверке XML-схемы для ограничения свойства исключительно по значению или по ссылке, или по nil-значению. В качестве другого примера проверка XML-схемы не поддерживает применение совместных ограничений, таких как требование, чтобы "extent" в виде "EX_GeographicBoundingBox" или "EX_GeographicDescription" использовался в объекте "MD_Identification", когда уровень иерархии в "MD_Metadata" равен "dataset" (набор данных).

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

A.2 Классы соответствия

A.2.1 Общие положения

Классы соответствия для требований, связанных с экземплярами документов XML (цель соответствия), тестируют посредством проверки XML-схемы, использования наборов правил Schematron и просмотра экземпляров документов. Требования к классу соответствия и тесты представлены в таблицах A.1-A.9.

A.2.2 Базовый класс соответствия

Этот класс соответствия проверяет соответствие требованию кодирования свойств ядра метаданных. Целью соответствия является экземпляр XML-документа.

Таблица A.1 - Класс соответствия (ядро метаданных XML)

A.2.3 Классы соответствия для модулей метаданных

Таблица A.2 - Классы соответствия для экземпляров модулей XML

A.2.4 Классы соответствия для документов обмена метаданными

A.2.4.1 Общие положения

Классы соответствия, указанные в A.2.4.2-A.2.4.8, определяют XML-схему, которая импортирует один или несколько модулей метаданных, чтобы обеспечить реализацию записей метаданных для различных сценариев использования. Цель соответствия - это экземпляр XML-документа с полными метаданными.

A.2.4.2 Класс соответствия: минимальный действительный экземпляр документа метаданных XML

Класс соответствия, указанный в таблице A.3, определяет минимальный документ метаданных, соответствующий ГОСТ Р 57668. Данный класс соответствия предназначен в качестве упрощенной отправной точки для тех профилей, которые будут выборочно использовать другие модули метаданных из этого документа и могут использовать другие реализации для некоторых модулей.

Таблица A.3 - Класс соответствия: минимальный действительный экземпляр метаданных XML

A.2.4.3 Класс соответствия: полная запись метаданных

Класс соответствия, указанный в таблице A.4, определяет запись метаданных, которая содержит все элементы, необходимые для создания полной записи метаданных согласно ГОСТ Р 57668, описывающей любой тип геопространственного ресурса или сервиса. Целью этого класса является поддержка стандартных сервисов каталогов, которые не реализуют расширения метаданных или не используют расширенные типы, определенные в пространстве имен геопространственных общих расширенных типов. Объявив о соответствии этому классу, приложение может четко указать, что оно не поддерживает эти расширения.

Таблица A.4 - Класс соответствия: полный действительный экземпляр метаданных XML

A.2.4.4 Класс соответствия: метаданные, использующие геопространственные общие расширенные типы

Класс соответствия, указанный в таблице A.5, определяет тесты для проверки записей метаданных, которые включают все элементы метаданных ИСО, связанные с MD_Metadata, за исключением пространства имен расширения метаданных, и подстановки для символьных строк из пространства имен геопространственных общих расширений. Приложения, объявляющие соответствие этому классу, должны распознавать и правильно интерпретировать подстановки для символьных строк из пространства имен геопространственных общих расширений. Причем расширенные приложения, объявляющие соответствие этому классу, могут и не обрабатывать записи расширенных метаданных без ошибок.

Таблица A.5 - Класс соответствия: Действительный экземпляр метаданных XML с расширенными типами

A.2.4.5 Класс соответствия: расширенная запись метаданных

Класс соответствия, указанный в таблице A.6, задает тесты для определения того, реализована ли запись метаданных, в которой расширена модель по ГОСТ Р 57668, в соответствии с указанными правилами (см. [3]). Приложения, объявляющие о соответствии этому классу, должны иметь действительный корневой XML-элемент mdb:MD_Metadata и уметь обрабатывать информацию, представленную в разделе MD_MetadataExtension экземпляров документов метаданных. Модульная реализация, определенная в настоящем стандарте, разрешает расширения метаданных, которые заменяют различные конкретные элементы для одного или нескольких необязательных свойств MD_Metadata, реализуемых с помощью типов свойств абстрактных классов. В этих случаях следует использовать содержимое MD_MetadataExtensionlnformation для документирования расширенного содержимого.

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

Таблица A.6 - Класс соответствия: действительный экземпляр метаданных XML с расширенной моделью содержимого

A.2.4.6 Класс соответствия "Действительный экземпляр каталога"

Каталог - это набор информационных элементов (CT_Items), управление которыми осуществляется с помощью реестра (CT_Catalogue). Абстрактная концепция каталога (см. [3]) для согласования различных концепций каталога серии стандартов ИСО по географической информации, таких как PF_PortrayalCatalogue (см. [10]) и FC_FeatureCatalogue (см. [9]), реализована в настоящем стандарте для совместимости с ГОСТ Р 57668. Класс соответствия, указанный в таблице A.7, определяет тесты для проверки действительных экземпляров конкретных элементов, которые заменяют абстрактные CT_Catalogue и CT_Item для установления списка действительных каталогов информационных элементов.

Таблица A.7 - Класс соответствия "Действительный экземпляр каталога XML"

A.2.4.7 Класс соответствия "Приложение метаданных"

Класс соответствия, указанный в таблице A.8, определяет тесты для проверки XML-экземпляров, которые агрегируют метаданные для составных ресурсов с корневым элементом в группе подстановок для абстрактного DS_Aggregate. Экземпляры метаданных, связанные через ассоциацию "has" с членами агрегата, имеют корневой элемент в группе подстановок для MD_Metadata и могут включать все элементы метаданных ИСО, связанные с MD_Metadata, включая пространство имен расширения метаданных, а также элементы замены для символьных строк из пространства имен геопространственных общих расширений. Пользователям пакета приложения метаданных может понадобиться определить те профили, которые ограничивают использование расширенных типов, расширений метаданных или других модулей метаданных, для упрощения требований к разработке программного обеспечения.

Таблица A.8 - Класс соответствия "Действительный экземпляр XML пространства имен приложения метаданных"

A.2.4.8 Класс соответствия: Пакет метаданных для передачи данных

Класс соответствия, указанный в таблице A.9, определяет тесты для проверки экземпляров документов XML, реализующих передачу данных с использованием пакетов, которые объединяют файлы, содержащие ресурсы, записи метаданных, документирующие ресурсы, и необязательные дополнительные файлы, которые задокументированы в сопроводительном экземпляре каталога.

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

Таблица A.9 - Класс соответствия "Действительный экземпляр XML пространства имен метаданных для передачи данных"

Приложение B

(справочное)

XML-ресурсы географических метаданных

B.1 XML-схемы, определенные в настоящем стандарте

Настоящий стандарт определяет содержимое 27 пространств имен XML, установленных соглашением, с использованием следующих префиксов: cat, cit, gco, gcx, gex, gmw, Ian, mac, mas, mcc, mco, md1, md2, mda, mdb, mds, mdt, mех, mmi, mpc, mrc, mrd, mri, mrl, mrs, msr и srv. Каждый из этих префиксов пространства имен добавляется к //standards.iso.org/iso/19115/-3/, а номер версии схемы (основной и первой дополнительной), например "/1.0", после аббревиатуры пространства имен для формирования полного URI пространства имен. Эти схемы используют новую версию пространства имен (см. [3]), которое обычно обозначается с помощью префикса gco. Два примера экземпляров документов включены в приложение D.

XML-схемы, определенные в настоящем стандарте, можно найти в Интернете по адресу: //standards.iso.org/iso/19115/-3/, с подкаталогом для каждого пространства имен, обозначаемым трехсимвольным префиксом пространства имен по умолчанию (см. 5.2), и подкаталогом в каталоге пространства имен для каждой нумерованной версии выпуска XML-артефактов для этого пространства имен. Файлы в нумерованных папках выпуска содержат XML-схему, правила Schematron, списки кодов, примеры действительных и недействительных экземпляров схемы пространства имен для тестирования и веб-страницу HTML, содержащую пояснение пространства имен и ссылки на вспомогательные документы в папке пространства имен.

B.2 XML-схемы, не включенные в настоящий стандарт

В дополнение к пространствам имен, перечисленным в B.1, в настоящем стандарте использовано пространство имен географического языка разметки (gml) версии 3.2 (//www.opengis.net/gml/3.2). Достоверные XML-схемы, связанные с этим пространством имен, приведены в [8]. В настоящем стандарте применено пространство имен языка XLink версии 1.0 (https://www.w3.org/1999/xlink). Достоверные XML-схемы, связанные с этим пространством имен, также представлены в [8].

В настоящем стандарте использованы пространства имен абстрактных классов dqc и fcc, определенные в XML-реализациях ГОСТ Р 57773 и [9].

B.3 Дополнительные ресурсы

В целях большей доступности настоящего стандарта несколько файлов XML доступны для скачивания в каталоге "resources" по адресу: //standards.iso.org/iso/19115/resources. Они организованы в следующие категории поддержки: списки кодов (codelist), информация о пространстве имен и инструменты (namespacelnformationAndTools), а также преобразования (transforms).

Файлы XML, имеющие отношение к использованию списков кодов, доступные для скачивания, находятся в каталоге "codelist" раздела "resources". Подкаталог "cat" в этом каталоге содержит два файла. Файл codelists.html содержит HTML-список всех списков кодов, определенных в ГОСТ Р 57668, для общепринятого представления. Файл codelists.xml содержит все списки кодов, определенные в ГОСТ Р 57668, закодированные с использованием XML-схемы из пространства имен cat, определенного в настоящем стандарте. Подкаталог "gml" в каталоге "codelist" содержит отдельные файлы для каждого списка кодов, определенного в ГОСТ Р 57668, закодированного с использованием схемы словаря gml.

Каталог "namespacelnformationAndTools" содержит файл XML с информацией, описывающей все пространства имен ГОСТ Р 57668 и ГОСТ Р 57656 и файлы преобразования XSLT, которые преобразуют файл XML в //standards.iso.org/iso/19115/resources/namespaceSummary.html для отображения и использования людьми.

Каталог "transforms" содержит файлы преобразования XSLT: один, который преобразует экземпляры документов XML (см. [3]) в экземпляры документов XML, соответствующих настоящему стандарту, и другой, который преобразует экземпляры документов XML, представленных в настоящем стандарте, в экземпляры документов XML, (см. [3]). Необходимо учитывать, что обратное преобразование может потерять некоторую информацию, так как в настоящем стандарте есть элементы, которые отсутствуют в [3].

Приложение C

(справочное)

Описание кодирования

C.1 Введение в описание кодирования

Реализация схемы ГОСТ Р 57668 и связанных с ним стандартов следует правилам кодирования, приведенным в [5] (приложение A), и расширенным в [3], вместе с описанным выше шаблоном разделения пакетов. Исключения и реализации, основанные на внешних типах и для модулирования пакетов XML, подробно описаны в [3]; в реализации XML-схемы переработана упаковка этих элементов, чтобы изолировать зависимость от элементов GML в пространстве имен gmw.

С.2 Пространства имен XML

Пространства имен XML представляют собой специфичные для реализации группы элементов, предназначенные для упрощения повторного использования и расширения компонентов содержимого из концептуальной модели по ГОСТ Р 57668. В таблицах 3-5 приведены пространства имен для компонентов XML-схемы, используемые в представленной настоящем стандарте реализации. Подход к кластеризации элементов при этом разработан с целью упростить повторное использование компонентов XML и способствовать совместимости метаданных. Пространство имен mdb реализации XML-схемы в настоящем стандарте определяет корневой элемент (MD_Metadata), который имеет все свойства, определенные в ГОСТ Р 57668, и импортирует все необходимые пространства имен, требуемые для реализации этих свойств в экземпляре метаданных XML, соответствующем ГОСТ Р 57668.

На рисунке C.1 показаны отношения зависимостей между пространствами имен, используемыми для реализации ГОСТ Р 57668. Стереотип отношения "import" означает, что исходное пространство имен импортирует (зависит от) целевое пространство имен (на указывающем конце стрелки). Все пакеты импортируют пространство имен цитирования (cit). Следует обратить внимание на то, что все пакеты также импортируют географическое общее пространство имен (gco), которое, в свою очередь, импортирует XLink. Пакеты, которые используют элементы пространства имен GML, импортируют пространство имен gmw. Взаимосвязи со схемами для качества данных и каталогов объектов других стандартов ИСО по географической информации реализуются с помощью необязательных абстрактных классов.

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

Рисунок C.1 - Зависимости между пространством имен mds и другими пакетами пространств имен XML в настоящем стандарте

Приложение D

(справочное)

Примеры реализации

D.1 Пример минимальных метаданных

Следующий экземпляр документа XML включает только обязательные элементы по ГОСТ Р 57668 и получен исходя из примера, представленного в ГОСТ Р 57668-2017 (Е.2).

<?xml version="1.0" encoding="UTF-8"?>

<mdb:MD_Metadata xmlns="//standards.iso.org/iso/19115/-3/mdb/1.0"

xmlns:dqc="//standards.iso.org/iso/19157/-2/dqc/1.0"

xmlns:gco="//standards.iso.org/iso/19115/-3/gco/1.0"

xmlns:lan="//standards.iso.org/iso/19115/-3/lan/1.0"

xmlns:mcc="//standards.iso.org/iso/19115/-3/mcc/1.0"

xmlns:mdb="//standards.iso.org/iso/19115/-3/mdb/1.0"

xmlns:cit="//standards.iso.org/iso/19115/-3/cit/1.0"

xmlns:mri="//standards.iso.org/iso/19115/-3/mri/1.0"

xmlns:gex="//standards.iso.org/iso/19115/-3/gex/1.0"

xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="//standards.iso.org/iso/19115/-3/mdb/1.0 mdb.xsd">

<mdb:contact>

<cit:CI_Responsibility>

<cit:role>

<cit:CI_RoleCode codeList="//standards.iso.org/iso/19115/resources/

Codelist/cat/codeLists.xml#CI_RoleCode" codeListValue="custodian">custodian</cit:CI_RoleCode>

</cit:role>

<cit:party>

<cit:CI_Organisation>

<!-- имя или логотип является обязательным согласно ограничению, установленному Schematron -->

<cit:name>

<gco:CharacterString>Department of Primary Industries and Resources

SA</gco:CharacterString>

</cit:name>

</cit:CI_Organisation>

</cit:party>

</cit:CI_Responsibility>

</mdb:contact>

<mdb:datelnfo>

<cit:CI_Date>

<cit:date>

<gco:DateTime>2004-03-12T12:00:00</gco:DateTime>

</cit:date>

<cit:dateType>

<cit:CI_DateTypeCode codeList="//standards.iso.org/iso/19115/resources/Codelist/cat/codeLists.xml#creation" codeListValue="Creation"/>

</cit:dateType>

</cit:CI_Date>

</mdb:datelnfo>

<mdb:identificationlnfo>

<mri:MD_DataIdentification>

<mri:citation>

<cit:CI_Citation>

<cit:title>

<gco:CharacterString>Exploration Licences for

Minerals</gco:CharacterString>

</cit:title>

<!-- обязательно (dataType= creation) согласно ограничению, установленному правилом Schematron -->

<cit:date>

<cit:CI_Date>

<cit:date>

<gco:DateTime>1993-01-01T12:00:00</gco:DateTime>

</cit:date>

<cit:dateType>

<cit:CI_DateTypeCode codeList="//standards.iso.org/iso/19115/

resources/Codelist/cat/codeLists.xml#CI_DateTypeCode" codeListValue="publication">publication</cit:CI_DateTypeCode>

</cit:dateType>

</cit:CI_Date>

</cit:date>

</cit:CI_Citation>

</mri:citation>

<mri:abstract>

<gco:CharacterString>Location of all current mineral Exploration Licences issued under the Mining Act, 1971. Exploration Licences provide exclusive tenure rights to explore for mineral resources for up to a maximum of 5 years. Comment is sought on applications for Exploration Licences from numerous sources before granting. Exploration programs are subject to strict environmental and heritage conditions. Exploitation of identified resources shall be made under separate mineral production leases.</gco:CharacterString>

</mri:abstract>

<!-- обязательно, поскольку MD_MetadataScope не указан, и по умолчанию используется ’dataset’, установленный правилом Schematron -->

<mri:topicCategory>

<mri:MD_TopicCategoryCode>boundaries</mri:MD_TopicCategoryCode>

</mri:topicCategory>

<!-- ограничивающий прямоугольник необходим, поскольку mdb:MD_MetadataScope не задан; установлено правилом Schematron-->

<mri:extent>

<gex:EX_Extent>

<gex:description>

<gco:CharacterString>location description</gco:CharacterString>

</gex:description>

<gex:geographicElement>

<gex:EX_GeographicBoundingBox>

<gex:extentTypeCode>

<gco:Boolean>false</gco:Boolean>

</gex:extentTypeCode>

<gex:westBoundLongitude>

<gco:Decimal>129.0</gco:Decimal>

</gex:westBoundLongitude>

<gex:eastBoundLongitude>

<gco:Decimal>141.0</gco:Decimal>

</gex:eastBoundLongitude>

<gex:southBoundLatitude>

<gco:Decimal>-38.5</gco:Decimal>

</gex:southBoundLatitude>

<gex:northBoundLatitude>

<gco:Decimal>-26.0</gco:Decimal>

</gex:northBoundLatitude>

</gex:EX_GeographicBoundingBox>

</gex:geographicElement>

</gex:EX_Extent>

</mri:extent>

<!-- обязательно, если ресурс содержит текстовое содержимое (должно быть установлено просмотром) -->

<mri:defaultLocale>

<lan:PT_Locale>

<lan:language>

<lan:LanguageCode codeList="//standards.iso.org/iso/19115/resources/ Codelist/lan/LanguageCode.xml" codeListValue="eng">English</lan:LanguageCode>

</lan:language>

<lan:characterEncoding>

<lan:MD_CharacterSetCode codeList="//standards.isо.org/iso/19115/resources/

Codelist/lan/CharacterSetCode.xml" codeListValue="utf8">UTF-8</lan:MD_CharacterSetCode>

</lan:characterEncoding>

</lan:PT_Locale>

</mri:defaultLocale>

</mri:MD_DataIdentification>

</mdb:identificationlnfo>

</mdb:MD_Metadata>

D.2 Примеры с Vector Smart Map Level 0

Следующий экземпляр XML-документа содержит примеры метаданных из набора данных Vector Smart Map Level 0.

<?xml version="1.0" encoding="UTF-8"?>

<!-- VMAP 0 gmd экземпляр базового документа -->

<mdb:MD_Metadata xmlns="//standards.iso.org/iso/19115/-3/mds/1.0"

xmlns:fcc="//standards.iso.org/19110/fcc/1.0"

xmlns:gex="//standards.iso.org/iso/19115/-3/gex/1.0"

xmlns:mac="//standards.iso.org/iso/19115/-3/mac/1.0"

xmlns:mas="//standards.iso.org/iso/19115/-3/mas/1.0"

xmlns:mco="//standards.iso.org/iso/19115/-3/mco/1.0"

xmlns:mdb="//standards.iso.org/iso/19115/-3/mdb/1.0"

xmlns:mdq="//standards.iso.org/iso/19157/-2/mdq/1.0"

xmlns:mds="//standards.iso.org/iso/19115/-3/mds/1.0"

xmlns:mmi="//standards.iso.org/iso/19115/-3/mmi/1.0"

xmlns:mpc="//standards.iso.org/iso/19115/-3/mpc/1.0"

xmlns:mrc="//standards.iso.org/iso/19115/-3/mrc/1.0"

xmlns:mrd="//standards.iso.org/iso/19115/-3/mrd/1.0"

xmlns:mrl="//standards.iso.org/iso/19115/-3/mrl/1.0"

xmlns:mrs="//standards.iso.org/iso/19115/-3/mrs/1.0"

xmlns:msr="//standards.iso.org/iso/19115/-3/msr/1.0"

xmlns:srv="//standards.iso.org/iso/19115/-3/srv/2.0"

xmlns:dgc="//standards.iso.org/iso/19115/-3/dgc/1.0"

xmlns:gco="//standards.iso.org/iso/19115/-3/gco/1.0"

xmlns:lan="//standards.iso.org/iso/19115/-3/lan/1.0"

xmlns:mcc="//standards.iso.org/iso/19115/-3/mcc/1.0"

xmlns:cit="//standards.iso.org/iso/19115/-3/cit/1.0"

xmlns:mri="//standards.iso.org/iso/19115/-3/mri/.0"

xmlns:gml="//www.opengis.net/gml/3.2"

xmlns:xlink="https://www.w3.org/1999/xlink"

xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="//standards.iso.org/iso/19115/-3/mds/1.0 mds.xsd" uuid="US_NGA_VPF_VMAP0" id="VMAP0">

<mdb:defaultLocale>

<lan:PT_Locale>

<lan:language>

<lan:LanguageCode codeList="//standards.iso.org/iso/19115/resources/Codelist/ lan/LanguageCode.xml" codeListValue="eng">English</lan:LanguageCode>

</lan:language>

<lan:characterEncoding>

<lan:MD_CharacterSetCode codeList="//standards.iso.org/iso/19115/resources/ Codelist/lan/CharacterSetCode.xml" codeListValue="utf8">UTF-8</lan:MD_CharacterSetCode>

</lan:characterEncoding>

</lan:PT_Locale>

</mdb:defaultLocale>

<mdb:contact>

<cit:CI_Responsibility>

<cit:role>

<cit:CI_RoleCode codeList="//standards.iso.org/iso/19115/resources/Codelist/ сat/codeLists.xmlresources/Codelist/cat/codeLists.xml#CI_RoleCode" codeListValue="publisher"/>

</cit:role>

<cit:party>

<cit:CI_Organisation>

<cit:name>

<gco:CharacterString>US National Geospatial- Intelligence

Agency</gco:CharacterString>

</cit:name>

<cit:contactlnfo>

<cit:CI_Contact>

<cit:phone/>

<cit:address xlink:href="#ID00003"/>

<cit:onlineResource xlink:href="#ID00009"/>

</cit:CI_Contact>

</cit:contactlnfo>

</cit:CI_Organisation>

</cit:party>

</cit:CI_Responsibility>

</mdb:contact>

<!-- Дата создания метаданных -->

<mdb:datelnfo>

<cit:CI_Date>

<cit:date>

<gco:DateTime>2004-03-14T12:00:00</gco:DateTime>

</cit:date>

<cit:dateType>

<cit:CI_DateTypeCode codeList="//standards.isо.org/iso/19115/resources/Codelist/ cat/codeLists.xmlresources/Codelist/ cat/codeLists.xml#CI_DateTypeCode" codeListValue="creation"/>

</cit:dateType>

</cit:CI_Date>

</mdb:datelnfo>

<mdb:metadataStandard>

<cit:CI_Citation>

<cit:title>

<gco:CharacterString>ISO 19115-1</gco:CharacterString>

</cit:title>

<cit:edition>

<gco:CharacterString>2003</gco:CharacterString>

</cit:edition>

</cit:CI_Citation>

</mdb:metadataStandard>

<!-- ИНФОРМАЦИЯ О СИСТЕМЕ ПРИВЯЗКИ -->

<mdb:referenceSystemlnfo>

<mrs:MD_ReferenceSystem>

<mrs:referenceSystemldentifier>

<mcc:MD_Identifier>

<mcc:authority>

<cit:CI_Citation>

<cit:title>

<gco:CharacterString>World Geodetic System</gco:CharacterString>

</cit:title>

</cit:CI_Citation>

</mcc:authority>

<mcc:code>

<gco:CharacterString>WGS 84</gco:CharacterString>

</mcc:code>

</mcc:MD_Identifier>

</mrs:referenceSystemldentifier>

</mrs:MD_ReferenceSystem>

</mdb:referenceSystemlnfo>

<!-- КОНЕЦ ИНФОРМАЦИИ О СИСТЕМЕ ПРИВЯЗКИ -->

<!-- ИНФОРМАЦИЯ ОБ ИДЕНТИФИКАЦИИ -->

<mdb:identificationlnfо>

<mri:MD_DataIdentification>

<mri:citation>

<cit:CI_Citation>

<cit:title>

<gco:CharacterString>VMAPLV0</gco:CharacterString>

</cit:title>

<cit:date>

<cit:CI_Date>

<cit:date>

<gco:DateTime>2000-09-03T12:00:00</gco:DateTime>

</cit:date>

<cit:dateType>

<cit:CI_DateTypeCode codeList="//standards.iso.org/iso/19115/resources/Codelist/cat/codeLists.xml#CI_DateTypeCode" codeListValue="publication"/>

</cit:dateType>

</cit:CI_Date>

</cit:date>

<cit:presentationForm>

<cit:CI_PresentationFormCode codeList="//standards.iso.org/iso/19115/resources/Codelist/cat/codeLists.xml#CI_PresentationForm Code" codeListValue="mapDigital"/>

</cit:presentationForm>

</cit:CI_Citation>

</mri:citation>

<mri:abstract>

<gco:CharacterString>Vector Map: a general purpose database design to support GIS applications</gco:CharacterString>

</mri:abstract>

<mri:status>

<mcc:MD_ProgressCode codeList="//standards.iso.org/iso/19115/resources/ Codelist/cat/codeLists.xml#MD_ProgressCode" codeListValue="completed"/>

</mri:status>

<mri:pointOfContact>

<cit:CI_Responsibility id="ID00001">

<cit:role>

<cit:CI_RoleCode codeList="//standards.iso.org/iso/19115/resources/ Codelist/cat/codeLists.xml#CI_RoleCode" codeListValue="originator"/>

</cit:role>

<cit:party>

<cit:CI_Organisation>

<cit:name>

<gco:CharacterString>US National Geospatial-Intelligence

Agency</gco:CharacterString>

</cit:name>

<cit:contactlnfo>

<cit:CI_Contact id="ID00002">

<cit:phone>

<cit:CI_Telephone>

<cit:number>

<gco:CharacterString>888-888-8888</gco:CharacterString>

</cit:number>

</cit:CI_Telephone>

</cit:phone>

<cit:address>

<cit:CI_Address id="ID00003">

<cit:deliveryPoint>

<gco:CharacterString>4600 Sangamore Rd</gco:CharacterString>

</cit:deliveryPoint>

<cit:city>

<gco:CharacterString>Bethesda</gco:CharacterString>

</cit:city>

<cit:administrativeArea>

<gco:CharacterString>MD</gco:CharacterString>

</cit:administrativeArea>

<cit:postalCode>

<gco:CharacterString>20816-5003</gco:CharacterString>

</cit:postalCode>

<cit:country>

<gco:CharacterString>United States</gco:CharacterString>

</cit:country>

</cit:CI_Address>

</cit:address>

<cit:onlineResource>

<cit:CI_OnlineResource id="ID00004">

<cit:linkage>

<gco:CharacterString>//geoengine.nga.mil</gco:CharacterString>

</cit:linkage>

<cit:protocol>

<gco:CharacterString>http</gco:CharacterString>

</cit:protocol>

<cit:function>

<cit:CI_OnLineFunctionCode codeList="//standards.iso.org/iso/19115/resources/Codelist/cat/codeLists.xml#CI_OnLineFunctionCode" codeListValue="download"/>

</cit:function>

</cit:CI_OnlineResource>

</cit:onlineResource>

</cit:CI_Contact>

</cit:contactlnfo>

<cit:individual>

<cit:CI_Individual>

<cit:positionName>

<gco:CharacterString>Director, NGA, ATTN:COD,

MS P-37</gco:CharacterString>

</cit:positionName>

</cit:CI_Individual>

</cit:individual>

</cit:CI_Organisation>

</cit:party>

</cit:CI_Responsibility>

</mri:pointOfContact>

<mri:spatialRepresentationType>

<mcc:MD_SpatialRepresentationTypeCode codeList="//standards.iso.org/iso/19115/ resources/Codelist/cat/codeLists.xml#MD_SpatialRepresentationTypeCode" codeListValue="vector"/>

</mri:spatialRepresentationType>

<mri:spatialResolution>

<mri:MD_Resolution>

<mri:equivalentScale>

<mri:MD_RepresentativeFraction>

<mri:denominator>

<gco:Integer>1000000</gco:Integer>

</mri:denominator>

</mri:MD_RepresentativeFraction>

</mri:equivalentScale>

</mri:MD_Resolution>

</mri:spatialResolution>

<mri:topicCategory>

<mri:MD_TopicCategoryCode>boundaries</mri:MD_TopicCategoryCode>

</mri:topicCategory>

<mri:topicCategory>

<mri:MD_TopicCategoryCode>elevation</mri:MD_TopicCategoryCode>

</mri:topicCategory>

<mri:topicCategory>

<mri:MD_TopicCategoryCode>inlandWaters</mri:MD_TopicCategoryCode>

</mri:topicCategory>

<mri:topicCategory>

<mri:MD_TopicCategoryCode>oceans</mri:MD_TopicCategoryCode>

</mri:topicCategory>

<mri:topicCategory>

<mri:MD_TopicCategoryCode>society</mri:MD_TopicCategoryCode>

</mri:topicCategory>

<mri:topicCategory>

<mri:MD_TopicCategoryCode>structure</mri:MD_TopicCategoryCode>

</mri:topicCategory>

<mri:topicCategory>

<mri:MD_TopicCategoryCode>transportation</mri:MD_TopicCategoryCode>

</mri:topicCategory>

<mri:topicCategory>

<mri:MD_TopicCategoryCode>utilitiesCommunication</mri:MD_TopicCategoryCode>

</mri:topicCategory>

<!-- Способ первый для указания области покрытия данных -->

<!-- Использование EX_GeographicBoundingBoxType для описания -->

<!-- области покрытия данных с помощью приблизительных координат -->

<!-- ЭТОТ МЕТОД ОБЯЗАТЕЛЬНЫЙ, ЕСЛИ УРОВЕНЬ -->

<!-- ИЕРАРХИИ ЭТИХ МЕТАДАННЫХ - "НАБОР ДАННЫХ" ->

<mri:extent>

<gex:EX_Extent>

<gex:description>

<gco:CharacterString>location description</gco:CharacterString>

</gex:description>

<gex:geographicElement>

<gex:EX_GeographicBoundingBox>

<gex:extentTypeCode>

<gco:Boolean>false</gco:Boolean>

</gex:extentTypeCode>

<gex:westBoundLongitude>

<gco:Decimal>-180.00</gco:Decimal>

</gex:westBoundLongitude>

<gex:eastBoundLongitude>

<gco:Decimal>180.00</gco:Decimal>

</gex:eastBoundLongitude>

<gex:southBoundLatitude>

<gco:Decimal>-90.00</gco:Decimal>

</gex:southBoundLatitude>

<gex:northBoundLatitude>

<gco:Decimal>90.00</gco:Decimal>

</gex:northBoundLatitude>

</gex:EX_GeographicBoundingBox>

</gex:geographicElement>

</gex:EX_Extent>

</mri:extent>

<!-- Способ второй для указания области покрытия данных -->

<!-- Использование EX_GeographicBoundingPolygonType для описания -->

<!-- области покрытия данных с помощью более точных координат -->

<!-- Убедитесь, что при использовании этого метода включена -->

<!-- правильная информация о системе координат -->

<mri:extent>

<gex:EX_Extent>

<gex:description>

<gco:CharacterString>location description</gco:CharacterString>

</gex:description>

<gex:geographicElement>

<gex:EX_BoundingPolygon>

<gex:extentTypeCode>

<gco:Boolean>false</gco:Boolean>

</gex:extentTypeCode>

<gex:polygon>

<gml:Polygon gml:id="p1">

<gml:exterior>

<gml:LinearRing>

<gml:posList>180.000000</gml:posList>

</gml:LinearRing>

</gml:exterior>

</gml:Polygon>

</gex:polygon>

</gex:EX_BoundingPolygon>

</gex:geographicElement>

</gex:EX_Extent>

</mri:extent>

<mri:extent>

<gex:EX_Extent>

<gex:description>

<gco:CharacterString>temporal extent of source information</gco:CharacterString>

</gex:description>

<gex:temporalElement>

<gex:EX_TemporalExtent>

<gex:extent>

<gml:TimePeriod gml:id="tp1">

<gml:begin>

<gml:TimeInstant gml:id="ti1">

<gml:timePosition>1992-04-01T00:00:00-00:00</gml:timePosition>

</gml:Timelnstant>

</gml:begin>

<gml:end>

<gml:TimeInstant gml:id="ti2">

<gml:timePosition>2002-02-23T00:00:00-00:00</gml:timePosition>

</gml:Timelnstant>

</gml:end>

</gml:TimePeriod>

</gex:extent>

</gex:EX_TemporalExtent>

</gex:temporalElement>

</gex:EX_Extent>

</mri:extent>

<mri:resourceFormat>

<mrd:MD_Format id="ID00005">

<mrd:formatSpecificationCitation>

<cit:CI_Citation>

<cit:title>

<gco:CharacterString>VPF</gco:CharacterString>

</cit:title>

<cit:edition>

<gco:CharacterString>9606</gco:CharacterString>

</cit:edition>

</cit:CI_Citation>

</mrd:formatSpecificationCitation>

</mrd:MD_Format>

</mri:resourceFormat>

<mri:resourceFormat>

<mrd:MD_Format id="ID00006">

<mrd:formatSpecificationCitation>

<cit:CI_Citation>

<cit:title>

<gco:CharacterString>VMap 0</gco:CharacterString>

</cit:title>

<cit:identifier>

<mcc:MD_Identifier>

<mcc:code>

<gco:CharacterString>MIL-V-89039</gco:CharacterString>

</mcc:code>

</mcc:MD_Identifier>

</cit:identifier>

</cit:CI_Citation>

</mrd:formatSpecificationCitation>

<mrd:amendmentNumber>

<gco:CharacterString>Ammendment 1</gco:CharacterString>

</mrd:amendmentNumber>

</mrd:MD_Format>

</mri:resourceFormat>

</mri:MD_DataIdentification>

</mdb:identificationlnfo>

<!-- КОНЕЦ ИНФОРМАЦИИ ОБ ИДЕНТИФИКАЦИИ ->

<mdb:distributionlnfо>

<mrd:MD_Distribution>

<mrd:distributor>

<mrd:MD_Distributor>

<mrd:distributorContact>

<cit:CI_Responsibility>

<cit:role>

<cit:CI_RoleCode codeList="//standards.iso.org/iso/19115/resources/ Codelist/cat/codeLists.xml#CI_RoleCode" codeListValue="distributor"/>

</cit:role>

<cit:party>

<cit:CI_Individual>

<cit:positionName>

<gco:CharacterString>Director, NGA, ATTN:COD,

MS P-37</gco:CharacterString>

</cit:positionName>

</cit:CI_Individual>

</cit:party>

<cit:party>

<cit:CI_Organisation>

<cit:name>

<gco:CharacterString>US National Geospatial-Intelligence Agency</gco:CharacterString>

</cit:name>

<cit:contactlnfo>

<cit:CI_Contact>

<cit:phone>

<cit:CI_Telephone>

<cit:number>

<gco:CharacterString>555-555-5555</gco:CharacterString>

</cit:number>

<cit:numberType>

<cit:CI_TelephoneTypeCode

codeList="//standards.iso.org/iso/19115/resources/ Codelist/cat/codeLists.xml#CI_TelephoneTypeCode" codeListValue="office"/>

</cit:numberType>

</cit:CI_Telephone>

</cit:phone>

<cit:address xlink:href="#ID00003"/>

</cit:CI_Contact>

</cit:contactlnfo>

</cit:CI_Organisation>

</cit:party>

</cit:CI_Responsibility>

</mrd:distributorContact>

<mrd:distributorFormat>

<mrd:MD_Format>

<mrd:formatSpecificationCitation>

<cit:CI_Citation>

<cit:title>

<gco:CharacterString>gzip</gco:CharacterString>

</cit:title>

<cit:alternateTitle>

<gco:CharacterString>GNU RFC 1952</gco:CharacterString>

</cit:alternateTitle>

</cit:CI_Citation>

</mrd:formatSpecificationCitation>

<mrd:amendmentNumber>

<gco:CharacterString>1.2.4</gco:CharacterString>

</mrd:amendmentNumber>

</mrd:MD_Format>

</mrd:distributorFormat>

<mrd:distributorTransferOptions>

<mrd:MD_DigitalTransferOptions>

<mrd:onLine>

<cit:CI_OnlineResource>

<cit:linkage>

<gco:CharacterString>//geoengine.nga.mil/ftpdir/archive/vpf_data/v0noa.tar.gz</ gco:CharacterString>

</cit:linkage>

<cit:function>

<cit:CI_OnLineFunctionCode codeList="//standards.iso.org/iso/19115/resources/Codelist/cat/codeLists.xml#CI_OnLineFunctionCode" codeListValue="download"/>

</cit:function>

</cit:CI_OnlineResource>

</mrd:onLine>

<mrd:onLine>

<cit:CI_OnlineResource>

<cit:linkage>

<gco:CharacterString>//geoengine.nga.mil/ftpdir/archive/vpf_data/v0sas.tar.gz</ gco:CharacterString>

</cit:linkage>

<cit:function>

<cit:CI_OnLineFunctionCode codeList="//standards.iso.org/iso/19115/resources/Codelist/cat/codeLists.xml#CI_OnLineFunctionCode" codeListValue="download"/>

</cit:function>

</cit:CI_OnlineResource>

</mrd:onLine>

<mrd:onLine>

<cit:CI_OnlineResource>

<cit:linkage>

<gco:CharacterString>//geoengine.nga.mil/ftpdir/archive/vpf_data/v0soa.tar.gz</gco:CharacterString>

</cit:linkage>

<cit:function>

<cit:CI_OnLineFunctionCode codeList="//standards.iso.org/iso/19115/resources/Codelist/cat/codeLists.xml#CI_OnLineFunctionCode" codeListValue="download"/>

</cit:function>

</cit:CI_OnlineResource>

</mrd:onLine>

</mrd:MD_DigitalTransferOptions>

</mrd:distributorTransferOptions>

</mrd:MD_Distributor>

</mrd:distributor>

<!-- CD-заказ для военных заказчиков -->

<mrd:distributor>

<mrd:MD_Distributor>

<mrd:distributorContact>

<cit:CI_Responsibility>

<cit:role>

<cit:CI_RoleCode codeList="//standards.iso.org/iso/19115/resources/Codelist/cat/codeLists.xml#CI_RoleCode" codeListValue="distributor"/>

</cit:role>

<cit:party>

<cit:CI_Individual>

<cit:name>

<gco:CharacterString>Defense Supply Center Rich-mond

(DLA)</gco:CharacterString>

</cit:name>

<cit:contactlnfo>

<cit:CI_Contact id="ID00007">

<cit:phone gco:nilReason="missing"/>

<cit:address>

<cit:CI_Address id="ID00008">

<cit:deliveryPoint>

<gco:CharacterString>8000 Jefferson Davis Hwy</gco:CharacterString>

</cit:deliveryPoint>

<cit:city>

<gco:CharacterString>Richmond</gco:CharacterString>

</cit:city>

<cit:administrativeArea>

<gco:CharacterString>VA</gco:CharacterString>

</cit:administrativeArea>

<cit:postalCode>

<gco:CharacterString>23297</gco:CharacterString>

</cit:postalCode>

<cit:country>

<gco:CharacterString>United States</gco:CharacterString>

</cit:country>

</cit:CI_Address>

</cit:address>

<cit:onlineResource>

<cit:CI_OnlineResource>

<cit:linkage>

<gco:CharacterString>//www.dscr.dla.mil/pc9</ gco:CharacterString>

</cit:linkage>

<cit:function>

<cit:CI_OnLineFunctionCode codeList="//standards.iso.org/iso/19115/resources/Codelist/cat/codeLists.xml#CI_OnLineFunctionCode" codeListValue="order"/>

</cit:function>

</cit:CI_OnlineResource>

</cit:onlineResource>

</cit:CI_Contact>

</cit:contactlnfo>

</cit:CI_Individual>

</cit:party>

</cit:CI_Responsibility>

</mrd:distributorContact>

<mrd:distributorFormat>

<mrd:MD_Format>

<mrd:formatSpecificationCitation>

<cit:CI_Citation>

<cit:title>

<gco:CharacterString>VPF</gco:CharacterString>

</cit:title>

<cit:identifier>

<mcc:MD_Identifier>

<mcc:code>

<gco:CharacterString>MIL-STD-2407</gco:CharacterString>

</mcc:code>

</mcc:MD_Identifier>

</cit:identifier>

</cit:CI_Citation>

</mrd:formatSpecificationCitation>

<mrd:amendmentNumber>

<gco:CharacterString>9606</gco:CharacterString>

</mrd:amendmentNumber>

</mrd:MD_Format>

</mrd:distributorFormat>

<mrd:distributorTransferOptions>

<mrd:MD_DigitalTransferOptions>

<mrd:offLine>

<mrd:MD_Medium>

<mrd:name>

<cit:CI_Citation>

<cit:title>

<gco:CharacterString>cdROM</gco:CharacterString>

</cit:title>

</cit:CI_Citation>

</mrd:name>

<mrd:volumes>

<gco:Integer>4</gco:Integer>

</mrd:volumes>

<mrd:mediumFormat>

<mrd:MD_MediumFormatCode codeList="//standards.iso.org/iso/19115/resources/Codelist/cat/codeLists.xml#MD_MediumFormatCode" codeListValue="iso9660"/>

</mrd:mediumFormat>

</mrd:MD_Medium>

</mrd:offLine>

</mrd:MD_DigitalTransferOptions>

</mrd:distributorTransferOptions>

</mrd:MD_Distributor>

</mrd:distributor>

</mrd:MD_Distribution>

</mdb:distributionlnfo>

<!-- КАЧЕСТВО ДАННЫХ И ПРОИСХОЖДЕНИЕ (Пока нет XML-схемы, не удается проверить эту часть, поэтому она закомментирована...-->

<mdb:dataQualitylnfо>

<mdq:DQ_DataQuality>

<mdq:scope>

<mcc:MD_Scope>

<mcc:level>

<mcc:MD_ScopeCode codeList="//standards.iso.org/iso/19115/resources/Codelist/cat/codeLists.xml#MD_ScopeCode" codeListValue="dataset"/>

</mcc:level>

</mcc:MD_Scope>

</mdq:scope>

<mdq:report>

<mdq:DQ_DomainConsistency>

<mdq:measure>

<mdq:DQ_MeasureReference>

<mdq:nameOfMeasure>

<gco:CharacterString>Attribute Completeness Percentage</gco:CharacterString>

</mdq:nameOfMeasure>

</mdq:DQ_MeasureReference>

</mdq:measure>

<mdq:result>

<mdq:DQ_ConformanceResult>

<mdq:specification>

<cit:CI_Citation>

<cit:title>

<gco:CharacterString>MIL-V-89039</gco:CharacterString>

</cit:title>

<cit:date>

<cit:CI_Date>

<cit:date>

<gco:DateTime>1995-02-09T00:00:00Z</gco:DateTime>

</cit:date>

<cit:dateType>

<cit:CI_DateTypeCode codeList="//standards.iso.org/iso/19115/resources/Codelist/cat/codeLists.xml#CI_DateTypeCode" codeListValue="creation"/>

</cit:dateType>

</cit:CI_Date>

</cit:date>

</cit:CI_Citation>

</mdq:specification>

<mdq:explanation>

<gco:CharacterString>All features in this library have valid attribute codes assigned to them in accordance with this specification</gco:CharacterString>

</mdq:explanation>

<mdq:pass>

<gco:Boolean>true</gco:Boolean>

</mdq:pass>

</mdq:DQ_ConformanceResult>

</mdq:result>

</mdq:DQ_DomainConsistency>

</mdq:report>

</mdq:DQ_DataQuality>

</mdb:dataQualitylnfo>

<mdb:resourceLineage>

<mrl:LI_Lineage>

<mrl:statement>

<gco:CharacterString>HISTORICAL BACKGROUND - "While the fifth edition of NOAMER has evolved from previous digital version, the majority of the feature content is based on the National Imagery and Mapping Agency’s (NIMA) hardcopy Operational Navigational Chart (ONC) series. The initial digital version of VMap0 was the Digital Chart of the World and was NIMA’s first Vector Product Format (VPF) product. The DCW was released in 1992. With the ongoing development of the VPF Military Standard and the advent of the VMap0 product specification, a new version of the database was needed. VMap 0 library, NOAMER, Edition 4 was released in 1997.</gco:CharacterString>

</mrl:statement>

</mrl:LI_Lineage>

</mdb:resourceLineage>

<!-- КОНЕЦ КАЧЕСТВА ДАННЫХ И ПРОИСХОЖДЕНИЯ -->

<!-- ОГРАНИЧЕНИЯ -->

<mdb:metadataConstraints>

<mco:MD_SecurityConstraints>

<mco: classification>

<mco:MD_ClassificationCode codeList="//standards.iso.org/iso/19115/resources/Codelist/cat/codeLists.xml#MD_ClassificationCode" codeListValue="unclassified"/>

</mco:classification>

<mco:handlingDescription>

<gco:CharacterString>RELEASABILITY - unrestricted</gco:CharacterString>

</mco:handlingDescription>

</mco:MD_SecurityConstraints>

</mdb:metadataConstraints>

<!-- КОНЕЦ ОГРАНИЧЕНИЙ -->

</mdb:MD_Metadata>

Приложение ДА

(справочное)

Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте

Таблица ДА.1

Библиография