Приложение Е (справочное). Реализация метаданных

Приложение Е
(справочное)

Реализация метаданных

Е.1 Предисловие

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

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

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

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

Настоящее приложение включает четыре пункта: Е.2 имеет дело с простыми ресурсами; Е.3 - с более сложными ресурсами; Е.4 - со сложными ресурсами, которые комбинируют доступ к данным, структуру данных и содержание; Е.5 приводит использование MD_Scope для метаданных, описывающих агрегаты, серии и другие типы ресурсов.

Е.2 Простые ресурсы

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

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

Е.3 Комплексные ресурсы

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

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

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

Рассмотрим набор данных, который состоит из наблюдаемых или смоделированных параметров определенного количества высот или глубин, и связанный набор данных, который обеспечивает граничные условия на поверхности или производные значения этих параметров, усредненных по всем уровням. Первый использует трехмерное MD_SpatialRepresentation, второй - двухмерное MD_SpatialRepresentation. У этих двух ресурсов есть отличающийся, но связанный MD_ContentInformation - те же свойства, но различные измерительные процедуры. Возможно также некоторое изменение в качестве данных или информации о распространении для этих двух наборов данных, но при этом большая часть метаданных, описывающих их, была бы одинаковой. Настоящий стандарт позволяет множественность объектов MD_SpatialRepresentation и MD_ContentInformation в единственном объекте MD_Metadata, таким образом, допустимо организовать метаданные, описывающие эти ресурсы, как показано в Case 1 на рисунке Е.1. Этот подход использует единственную сущность MD_Metadata, которая содержит 2D-объект MD_SpatialRepresentation, 3Dобъект MD_SpatialRepresentation и единственный объект MD_ContentInformation, который содержит все параметры. Такое размещение включает требуемую информацию, но нельзя сказать, какие параметры доступны для двухмерных и какие для трехмерных объектов и аналогично для другого распределения или информации о качестве, которые могут варьировать между двухмерными усредненными данными и трехмерными отдельно измеренными данными. Эта неоднозначность не может быть разрешена разделением параметров в два класса MD_ContentInformation, как показано в Case 2 на рисунке Е.1. Нельзя определить, с каким классом MD_SpatialRepresentation какой из классов MD_ContentInformation связан.

Настоящий стандарт предоставляет два альтернативных решения, чтобы разрешить эту неоднозначность.

Первый подход - группировка на более высоком уровне, используя конкретную сущность DS_Series, которая является подтипом абстрактного DS_Aggregate (см. Case 3 на рисунке Е.1). Три объекта MD_Metadata, каждый с различной областью применения, включены в сущность DS_Series. Объект с областью scope = series содержит общие метаданные для всей совокупности. Объект с областью применения, равной dimensionGroup, содержится в сущности DS_Dataset и содержит сущности 2D и 3D MD_SpatialRepresentation вместе с соответствующими сущностями MD_ContentInformation.

Рисунок E.1 - Области применения метаданных

Второй подход - это представление каждого параметра с отдельной, автономной сущностью MD_Metadata и использование сущности MD_AssociatedResource для указания ассоциации между ресурсами (используя элемент имени) и между записями метаданных, описывающими ресурсы (metadataReference) (см. рисунок Е.2).

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

Второй подход может быть более подходящим в приложениях каталога, в которых пользователь ищет данные для определенного пользовательского сценария и, вероятно, предпочтет один из наборов данных, но не оба. В этом случае полная сущность MD_Metadata - это сущность, с которой работает большинство поисковых приложений каталога при использовании метаданных ИСО. Более сложные кодировки метаданных, включающие подтипы DS_Aggregate и включение содержания ссылкой (или неявное наследование для необязательных элементов), требуют, чтобы более сложное клиентское программное обеспечение было предоставлено пользователям. Использование ассоциаций с явной семантикой (использующий MD_AssociatedResource) обеспечивает модель, позволяющую пользователям перемещаться между связанными ресурсами в поисковом контексте.

Примечание - Элемент ассоциации TypeCode может быть использован для указания природы отношений.

Рисунок Е.2 - Ассоциация MD_AssociatedResource между метаданными для связанных ресурсов

В типе ассоциации, описанной выше, неоднозначность существует везде, где отдельный класс включает множество повторяемых атрибутов. Настоящий стандарт применим ко многим из этих ситуаций. Например, в исходном стандарте объекты MD_Metadata могли включать многократные hierarchyLevels и многократные hierarchyLevelNames без механизма для соединения определенного уровня с именем. С этим связано добавление объекта MD_Scope, который связывает определенное имя с определенным resourceScope. К другим неоднозначностям должны быть адресованы многократные экземпляры родительского класса.

Другая возможная иерархия метаданных показана на рисунке Е.3. В этом случае пространственный набор данных описан как совокупность типов объектов и типов атрибутов с совокупностью экземпляров объектов и атрибутов. Снова требуется комбинация всех метаданных для описания полной совокупности. Такой подход мог бы использоваться, чтобы задокументировать базу данных, в которой сущности DS_Dataset могли бы описать отдельные таблицы (область применения = набор данных или featureType), определение атрибутов (столбцы) в таблицах и отдельные экземпляры атрибута. На практике документацию на уровне экземпляра объекта обычно применяют к многократным экземплярам объекта (или строки таблицы) в наборе данных, в этом случае ассоциация обычно реализуется внешними ключами (ссылки) от отдельных функций к применяемой сущности MD_Metadata.

Рисунок Е.3 - Агрегация метаданных для описания составного набора данных

Е.4 Связанные наборы данных и сервисы: Multiple MD_Identification Objects

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

Один подход - использование соглашений с элементами содержания CI_OnlineResource, включенными в MD_Distribution/MD_DigitalTransferOptions, чтобы предоставить основную информацию о связи, обычно ссылаясь на документы описаний сервисов, такие как Web Services Description Language (WSDL), Web Application Description Language (WADL), OGC GetCapabilities, OpenSearchDescription и т.д., которые определены протоколом каждого сервиса. Этот подход основан на логике, что клиенты, которые могут использовать данную спецификацию сервиса, наиболее вероятно, будут в состоянии проанализировать и интерпретировать специфичное для сервиса самоописание, чем описание сервиса в [10]. Этот подход используется для метаданных, описывающих пространственные сервисы Open Geospatial Consortium, такие как Web Map Service (WMS), Web Feature Service (WFS), сервисы Web Coverage Service (WCS) (например, INSPIRE, Esri CSWArcMap Client), обслуживающие отдельные объекты или слои, но его ограничения для описания нестандартных или более сложных ресурсобазированных сервисов с большим разнообразием данных и опций запросов вызвали разработку [10], чтобы обеспечить более устойчивую модель для описания сервисов.

Другой подход - идентификационные элементы сервисов, описанные в [10], могут быть объединены с приведенными в настоящем стандарте, чтобы описать сервисы вместе с данными, которым они служат. Настоящий стандарт поддерживает включение любого количества объектов MD_DataIdentification и SV_ServiceIdentification в одном MD_Metadataentity. Эта возможность полезна:

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

2) метаданных, описывающих сервис, который служит нескольким ресурсам.

В этих ситуациях прочной связи единственный объект MD_Metadata включал бы:

1) единственный объект MD_DataIdentification с множественными объектами SV_ServiceIdentification или

2) единственный объект SV_ServiceIdentification с множественными объектами MD_DataIdentification.

В любом случае MD_Metadata включал бы объекты MD_Scope для набора данных и сервиса, и намерение объекта MD_Metadata будет состоять в том, чтобы указать, что набор данных и сервис обрабатываются как единый неделимый ресурс. Этот подход в настоящее время используется для наборов данных, к которым получает доступ THREDDS (Thematic Realtime Environmental Distributed Data Services - Тематические экологические распределенные сервисы передачи данных в реальном времени), предоставляемый University Corporation for Atmospheric Research (UCAR - Университетская корпорация атмосферных исследований) в Баулдере, Колорадо, США.

Записи, которые включают множественные объекты MD_Identification, могли вызвать неоднозначное толкование относительно того, какие метаданные в записи связаны с различными объектами. На рисунке Е.4 исследована эта неоднозначность в случае с объектами идентификации данных и сервисов. Все объекты, включая DQ_DataQuality и ниже по обе стороны рисунка Е.4, могут быть непосредственно связаны с отдельными объектами MD_DataIdentification и SV ServiceIdentification. Объекты выше DQ_DataQuality связаны с объектом MD_Metadata таким образом, что они применяются ко всем объектам MD_Identification, включенным в запись. Объекты справа описывают содержание данных, то каким образом они были собраны и как они распространяются. Объекты более тесно связаны с набором данных, чем сервис. Это, вероятно, разумно, когда несколько сервисов доступны для того же набора данных (Case 1). В случае для единственного сервиса, служащего множественным наборам данных, это не работало бы, если только все наборы данных не имеют общее содержание, одинаковую информацию о сборе и о распространении.

В настоящем приложении не рассматриваются ситуации, которые включают множественные объекты MD_DataIdentification без объектов SV_ServiceIdentification или множественные объекты SV_ServiceIdentification без объектов MD_DataIdentification. Представляется, что в этом случае должны быть использованы классы DS_Aggregate с множественными объектами MD_Metadata, как рассматривалось выше.

Рисунок Е.4 - Ассоциации в записях с множественными объектами MD_Identification

Е.5 Область применения метаданных

Е.5.1 Введение

MD_Scope используется для того, чтобы описать охват и/или тип ресурса, который описывается записью метаданных или классом. Он включает MD_ScopeCode как краткий индикатор области применения, который может быть полезным в приложениях поиска и представления MD_ScopeDescription, чтобы обеспечить больше деталей.

Значения в списке MD_ScopeCodeList намеренно обобщены, а детализация этого приложения оставлена конкретному сообществу. Для того чтобы способствовать функциональной совместимости, использование кодов области применения должно быть тщательно задокументировано в любом практическом сообществе. В разделе Е.5 в общих чертах представлены возможные варианты применения кодов из списка кодов MD_ScopeCode и связанных кодов, включенных в [14], как часть списка MX_ScopeCode. Эти примеры приведены для того, чтобы обеспечить разумные начальные точки, и, конечно, не являются исчерпывающими.

Е.5.2 Метаданные агрегата и комплектов (необязательные)

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

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

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

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

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

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

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

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

Е.5.3 Метаданные набора данных (значение по умолчанию)

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

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

Е.5.4 Метаданные географического объекта и атрибута (необязательные)

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