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

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

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

Е.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 Метаданные географического объекта и атрибута (необязательные)

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

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

- featureInstance (экземпляр объекта) - пространственные конструкции (объекты), имеющие прямое соответствие с объектами реального мира. Сервисы пространственных данных могут по выбору поддерживать метаданные экземпляра объекта при их наличии и сделать такие метаданные доступными для запроса или извлечения. Метаданные экземпляра объекта вместе с метаданными типа объекта, типа атрибута и экземпляра атрибута будут сгруппированы в наборы данных, как определено в пункте Е.5.3. Однако, как правило, метаданные экземпляра объекта связаны непосредственно с объектом, например как атрибут объекта в базе данных, и не обязательно выделяются в отдельном наборе метаданных согласно полной совместимой схеме. Примером записей метаданных экземпляра объекта могут быть Сиднейская гавань, мост Золотые Ворота или определенная платформа наблюдения;

- attributeType/propertyType (тип атрибута/тип свойства) - цифровые параметры, которые описывают общий аспект сгруппированных пространственных примитивов (0-, 1-, 2-, и 3-мерные геометрические объекты). Сервисы пространственных данных могут выборочно поддерживать метаданные типа атрибута при их наличии и сделать такие метаданные доступными для запроса или извлечения. Метаданные типа атрибута вместе с метаданными типа объекта, экземпляра объекта и метаданные экземпляра атрибута будут сгруппированы в наборы данных, как указано в пункте Е.5.3. Примеры записей метаданных типа атрибута могут включать верхний клиренс, связанный с мостами, или экологические параметры, измеренные датчиком на платформе наблюдения;

- attributeInstance (экземпляры атрибута) - цифровые параметры, которые описывают определенный аспект экземпляра объекта. Сервисы пространственных данных могут выборочно поддерживать метаданные экземпляра атрибута при их наличии и сделать такие метаданные доступными для запроса или извлечения. Метаданные экземпляра атрибута вместе с метаданными типа объекта, экземпляра объекта и типа атрибута будут сгруппированы в наборы данных, как определено в пункте Е.5.3. Однако обычно метаданные экземпляра атрибута объекта связывают непосредственно с атрибутом объекта, например как атрибут атрибута объекта в базе данных, и не обязательно выделяются в отдельном наборе метаданных, как предусмотрено полной совместимой схемой. Примеры записей метаданных экземпляра атрибута могут включать верхний клиренс, связанный с определенным мостом через дорогу, или значение экологического параметра, измеренного датчиком в определенное время.

Е.5.5 Метаданные о сеансе сбора/полевого сбора данных (необязательные)

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

- collectionSession/fieldSession - данные, которые имеют общий набор метаданных, описывающих определенное событие сбора в лаборатории или в поле;

- sample (выборка) - метаданные, связанные с определенным физическим экземпляром;

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

Е.5.6 Метаданные группы размерности (необязательные)

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

Е.5.7 Метаданные модели (необязательные)

Результаты моделирования - важная часть среды данных о состоянии окружающей среды. Весьма значимо понимание источников наблюдения данных, алгоритмов обработки и версий, которые используются для получения этих результатов. ГОСТ Р 57656 значительно расширяет возможности настоящего стандарта в части происхождения и должен учитываться для использования в этих ситуациях. У метаданных, которые описывают результаты моделирования, имеется область применения = модель (scope = model).

Е.5.8 Метаданные о сервисах (необязательные)

В настоящее время разработан международный стандарт для описания сервисов [10]. Настоящий стандарт описывает объект SV_ServiceIdentification, который включает элементы для описания сервисов и связанных операций. Объекты MD_Metadata, которые включают объекты SV_ServiceIdentification, должны включать область применения = сервис (scope = service).

Е.5.9 Метаданные о программном обеспечении

В ГОСТ Р 57656 были добавлены элементы для описания программного обеспечения и обработки, использованной для создания продукта из ряда наблюдений. Добавленные элементы включают также СI_Citations. Для описания программного обеспечения должны использоваться скорее эти ссылки, а не MD_Metadata с областью применения = программное обеспечение (scope = software).

Е.5.10 Метаданные о тайлах (необязательные)

Многие крупные наборы данных дистанционного зондирования разделены на множество тайлов, для того чтобы упростить доступ и передачу поднаборов из подмножеств. У метаданных для этих тайлов область применения = тайл (scope = tile).

Е.5.11 Метаданные о метаданных (необязательные)

Метаданные, описывающие другие метаданные, будут иметь область применения = метаданные (scope = metadata).

Е.5.12 Метаданные об инициативе (необязательные)

Список DS_InitiativeTypeCode включает значения для описания многих типов данных, набора наблюдения и управленческих инициатив. Этот список кодов используется, чтобы описать агрегации таким образом, что aggregateDataSetIdentifier мог идентифицировать запись метаданных, которая описывает любой из этих типов инициатив. Область применения = инициатива (scope = initiative) обеспечивает общий тип для всех этих инициатив. Он может использоваться, чтобы описать проект или программу, которая может производить другие ресурсы. Отмечают также использование DS_InitiativeType для описания MD_AssociatedResource.

Е.5.13 Метаданные о документе (необязательные)

CI_Citation обеспечивает четкий механизм для цитирования документа, но есть много ситуаций, в которых было бы лучше предоставить более подробные описания других аспектов документа. Метаданные с областью применения = документ (scope = document) обеспечивают для этого определенный механизм.

Е.5.14 Метаданные о репозитарии (необязательные)

Метаданные о репозитарии могут включать контактную информацию и широкие описания типов данных, содержащихся в репозитарии. Они могут также включать информацию о качестве соответствия репозитария различным стандартам. Метаданные с областью применения = репозитарии (scope = repository) обеспечивают механизм для описания этих фасетов репозитария.